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SECTION  1 

INTRODUCTION  &  EXECUTIVE  SUMMARY 


1.1  BACKGROUND 

Satellite  communications  as  provided  by  the  Defense  Satellite 
Communications  System  (DSCS)  have  become  an  integral  part  of  the  Defense 
Communications  System.  In  providing  a  network  of  satellite-linked 
circuits,  DSCS  supports  a  variety  of  users  and  user  data  rates  ranging  from 
75  bps  (TTY)  to  wideband  data  requirements  as  high  as  10  Mbps.  Composed  of 
terminal,  space,  and  control  segments,  DSCS  has  now  entered  Phase  III  of 
its  evolution  with  the  launch  of  the  first  DSCS  III  satellite  in  October 
1982. 

The  continued  evolution  of  the  Defense  Satellite  Communications  System 
(DSCS)  involves  the  further  development  and  deployment  of  earth  terminals 
and  their  associated  equipment.  Elements  of  the  terminal  segment  include: 

e  the  Technical  Control  Facility,  providing  the  user  interface  to 
DSCS  and  any  necessary  signal  conditioning  equipment; 

•  the  Digital  Communications  Subsystem  (DCSS),  encompassing  the 
modulation,  multiplex,  coding,  and  processing  equipment  needed  to 
assemble  the  various  types  of  supported  user  data  into  a  digital 
format  suitable  for  transmission  through  the  DSCS  satellite 
network ; 

•  the  Interconnect  Facility  (ICF),  linking  the  TCF  and  DCSS 
equipment  when  they  are  physically  separated  at  a  particular 
installation;  and 

t  the  Link  Terminal  (LT),  providing  the  RF  subsystems  interfacing 
between  the  DCSS  at  70/700  MHz  IF  and  the  DSCS  space  segment. 
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DSCS  earth  terminals  incorporate  or  will  incorporate  subsystems  and 
equipment  such  as  the  DSCS  Electronic  Counter-Counter  Measures  Control 
Subsystem  (DECS),  the  DSCS  Frequency  Division  Multiple  Access  (FDMA) 

Control  Subsystem  (DFCS),  the  Integrated  Multiplex,  Patch  and  Test  (IMPAT) 
equipment,  etc.  While  the  DSCS  ground  segment  is  currently  defined  by 
groupings  of  such  subsystems  and  equipment,  the  groupings  are  not 
standardized — each  DSCS  terminal  is  typically  configured  uniquely. 

Generically,  the  terminal  equipment  can  be  seen  in  terms  of  the  equipment 
groups  of  Figure  1-1.  In  the  forward  direction,  user  signals  to  be 
transmitted,  after  any  needed  conditioning  performed  by  the  Technical 
Control  Facility,  are  routed  through  a  Main  Distribution  Frame  to 
multiplexers  and  further  signal  conditioning  equipment  (encryptors,  A/D 
converters,  etc.)  as  required.  The  employed  multiplexing  schemes  are  co¬ 
ordinated  retwork-wide,  thereby  establishing  the  desired  user  circuits. 
After  multiplexing,  the  signals  are  routed  to  the  modems  and  up-converters 
which  define  the  various  DSCS  satellite  channels.  User  signals  received  at 
the  earth  terminal  follow  a  similar  procedure  in  the  reverse  direction. 
Interconnection  of  the  terminal  equipment,  then,  defines  the  equipment 
chains  needed  to  support  the  user  circuits. 

Figure  1-1  also  indicates  the  capability  of  monitoring  and  controlling 
terminal  equipment.  Many  of  the  existing  or  planned  subsystems  incorporate 
control  and  status  monitoring  functions.  Future  terminals,  however,  may 
involve  an  integrated  approach  to  control  and  status  monitoring,  thereby 
requiring  further  intercommunication  between  terminal  devices.  One  such 
integrated  terminal  currently  envisioned  for  future  deployment  is  the 
Modularized  Integrated  Satellite  Terminal  (MIST),  a  light  terminal  intended 
to  support  a  maximum  user  data  throughput  of  10  Mbps. 

Currently,  a  terminal's  complement  of  equipment  is  arranged  by  modular 
racks.  The  Digital  Communications  Subsystem  (DCSS)  defines  22  different 
rack  configurations,  each  rack  provided  with  a  specific  equipment  set.  For 
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a  particular  earth  terminal's  communications  requirements,  the  necessary 
racks  (including  those  needed  to  provide  a  measure  of  equipment  redundancy) 
are  installed  and  interconnected  according  to  the  desired  terminal 
configuration.  Connections  are  generally  made  through  the  top  of  the  rack 
and/or  through  associated  patch  panels.  Note  that  equipment  failures  or 
routine  maintenance  generally  lead  to  changes  in  equipment  connections  more 
frequently  than  do  those  changes  required  for  network  or  terminal 
reconfigurations. 

The  current  rack-based  modularity,  however,  has  its  disadvantages.  Often, 
an  entire  rack  of  equipment  stands  idle  due  to  the  failure  of  only  one  of 
its  components.  Furthermore,  the  wiring  of  the  rack  assembly  does  not 
readily  allow  the  replacement  of  equipment  with  other  than  the  same 
component.  As  DSCS  earth  terminal  designs  evolve,  however,  the  ability  to 
replace  single  components  or  subsystems  rather  than  full  equipment  racks 
becomes  more  desirable.  This  goal  would  be  well  served  if  it  were  possible 
to  standardize  all  rack  assemblies  so  that  any  piece  of  equipment  could  be 
installed  into  the  rack.  The  problem  would  then  be  to  establish  the 
necessary  interconnections  between  equipment. 
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1.2  OBJECTIVES 

The  interconnection  of  DSCS  terminal  equipment  in  support  of  terminal 
integration  is  the  subject  of  this  study.  With  the  recent  advent  of 
inexpensive  distributed  computing  power,  the  interconnection  of  different 
information  processing  devices  has  become  more  and  more  important.  In 
office  and  industrial  environments,  the  desired  intercommunication  between 
devices  is  now  often  achieved  through  local  area  networks.  A  local  area 
network  (LAN)  efficiently  provides  the  needed  connectivity  between  devices 
by  allowing  all  units  to  share  a  common  transmission  medium  and/or  central 
device.  The  applicability  of  local  area  networks  to  accomplish  the 
interconnection  of  DSCS  subsystems  is  one  focus  of  this  report. 
Additionally,  the  use  of  digital  matrix  switching  technology — 
specifically,  use  of  the  IMPAT — as  a  means  to  interconnect  terminal 
equipment  is  considered. 

This  study,  then,  serves  to  assess  the  use  of  local  area  networks  and,  to 
some  extent,  digital  matrix  switching  in  DSCS  earth  terminals.  A 
fundamental  understanding  of  the  capabilities  of  local  area  networks  is 
provided  as  part  of  this  work  in  order  to  allow  the  reader  to  make  an 
informed  assessment  of  the  presented  material.  The  two  main  thrusts  of 
this  report  concern  the  type  of  earth  terminal  intercommunications  to  be 
supported  by  local  area  networks;  the  interconnection  of  equipment  in 
support  of  DSCS  user  circuits  and/or  the  interconnection  of  equipment  in 
support  of  the  flow  of  equipment  control  and  status  signals. 

The  report  is  organized  in  the  following  manner: 

•  Section  1  provides  an  introduction  and  executive  summary; 

•  Section  2  identifies  the  two  identified  communications  problems 
and  places  the  interconnection  of  terminal  devices  in  the  context 
of  a  layered  network  architecture; 
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t  Section  3  reviews  the  subsystems  composing  the  OSCS  earth 
terminals; 

•  Section  4  provides  an  introduction  to  local  area  network 
technology; 

•  Section  5  specifically  addresses  the  application  of  LAN 
technology  to  the  two  identified  intercommunication  roles; 

•  Section  6  considers  the  use  of  IMPAT  in  fulfilling  the 
intercommunication  needs; 

•  Appendix  A  documents  specific  OSCS  equipment  types  and  their 
interfaces; 

•  Appendix  B  provides  a  listing  of  commercially  available  LAN 
products;  and, 

•  Appendix  C  estimates  the  throughput  requirements  for  baseline 
light,  medium,  and  heavy  terminals. 

The  objectives  of  this  report  are  thus  to  identify  and  explore  issues 
concerning  the  use  of  local  area  network  technology  in  the  OSCS  earth 
terminals.  The  goals  of  any  such  application  are  reduced  implementation 
costs,  enhanced  system  modularity,  and  the  potential  to  reconfigure  and/or 
expand  the  terminal  interconnections.  Any  proposed  solution,  however,  must 
additionally  be  considered  in  terms  of  space  conservation,  reliability, 
maintainability,  communications  security,  system  complexity,  and 
transparency  from  the  point  of  view  of  the  OSCS  user  community. 
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APPLICATION  OF  LAN  TECHNOLOGY:  GOALS 


•  REDUCED  TERMINAL  IMPLEMENTATION  COSTS 

•  ENHANCED  MODULARITY  AND  FLEXIBILITY 

•  EXPANDABILITY 


APPLICATION  OF  LAN  TECHNOLOGY:  ISSUES 


COST 

SPACE  CONSERVATION 
RELIABILITY 
MAINTAINABILITY 
COmUNICATIONS  SECURITY 
SYSTEM  COMPLEXITY 

NETVnRK  PERFORMANCE;  E.G.,  DELAY  VS.  THROUGHPUT 


R850156-h 


1.3  EXECUTIVE  SUMMARY 

This  study  addresses  the  use  of  local  area  network  (LAN)  technology  in  the 
OSCS  earth  terminals,  indicating  issues  and  considerations  pertinent  to 
such  an  application.  This  assessment  of  LAN  technology  complements  the 
ongoing  effort  to  develop  an  integrated  earth  terminal  design  which  would 
allow  the  modular  deployment  of  DSCS  equipment  and  subsystems  and  would 
operate  under  either  central  or  distributed  command.  Use  of  LAN  technology 
would  support  intercommunications  among  devices  and  thereby  provide  the 
means  to  support  full  system/subsystem  integration  of  the  DSCS  earth 
terminals. 

Problem  Definition 


Two  types  of  device  intercommunication  may  be  identified:  the 
intercommunication  of  equipment  to  directly  provide  the  channels  needed  for 
DSCS  user  circuits  and  the  intercommunication  of  equipment  in  support  of 
control  and  status  monitoring  functions.  Intercommunications  in  support  of 
OSCS  user  circuits  must  provide  dedicated  channels  for  both  voice  and  data 
circuits,  the  data  circuits  spanning  a  wide  range  of  data  rates.  In 
addition,  the  interconnection  of  devices  must  provide  flexibility  and 
allow  re-routing  of  signal  flows  in  the  event  of  equipment  failure  or  DSCS 

I  network  and/or  terminal  configuration  changes.  Intercommunications  in 

support  of  control  and  status  monitoring  functions,  on  the  other  hand,  are 
not  subject  to  as  stringent  requirements,  allowing  considerably  more 
latitude  in  the  type  of  LAN  that  may  be  employed. 

Communications  networks  are  generally  seen  in  terms  of  the  switching 
technique  employed  by  the  network.  Circuit,  message,  and  packet  switching 
are  well-known  designations  for  switching  types.  While  local  area  networks 

I  typically  support  computer- to-computer  communications  by  providing  packet- 

switched  communications,  the  DSCS  network  provides  circuit-switched 
services  to  its  users.  If  local  area  networks  are  to  be  used  for  the 
intercommunication  of  terminal  equipment  in  support  of  DSCS  user  circuits, 

I 
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then  the  local  area  network  must  possess  circuit-switched  capabilities. 

The  intercommunication  of  control  and  status  signals,  by  contrast,  is  not 
restricted  to  any  particular  switching  technique. 

The  interconnection  between  devices  anticipated  for  DSCS  earth  terminal 
integration  requires  some  common  basis  for  meaningful  communication, 
especially  in  regard  to  the  intercommunication  of  control  and  status 
signals.  Layered  network  architectures  have  been  developed  to  provide  a 
logical  and  hierarchical  division  of  responsibilities  in  support  of  device 
intercommunications.  For  example,  the  Open  Systems  Interconnection  (OSI) 
Reference  Model,  established  by  the  International  Organization  for 
Standardization  (ISO),  defines  a  seven-layer  architecture  (illustrated  in 
Figure  1-2)  demarcating  the  responsibilities  required  in  the 
intercommunications  between  systems.  The  establishment  and  use  of 
standardized  protocols  to  fulfill  the  requirements  of  each  layer  will 
ultimately  permit  disparate  devices  to  communicate  with  one  another.  In 
developing  standards  for  local  area  networks,  the  IEEE  802  committee  has 
closely  paralleled  the  OSI  architecture  in  order  to  define  the  standard 
operations  and  characteristics  which  802  local  area  networks  must  exhibit. 

Such  a  layered  architecture  naturally  leads  to  local  area  networks  which 
operate  transparently,  invisible  to  the  LAN  users.  This  transparency  is 
essential  if  LAN  technology  is  to  be  used  to  interconnect  devices  in 
support  of  DSCS  user  circuits.  The  concept  of  a  layered  network 
architecture  is  important  too  in  the  intercommunication  of  DSCS  equipment 
control  and  status  signals — above  the  layers  of  communication 
responsibility  provided  by  the  local  area  network,  there  must  be 
established  mechanisms  by  which  different  equipment  types  may  signal  and 
respond  to  one  another.  Merely  providing  the  means  of  intercommunication 
by  employing  a  local  area  network  does  not  guarantee  that  communicated 
signals  will  be  correctly  interpreted.  This  issue  is  critical  to  the 
design  of  an  integrated  DSCS  earth  terminal,  although  not  wholly  within  the 
scope  of  this  study — many  of  the  equipment  types  to  be  interconnected  via 
a  LAN  are  "dumb"  devices,  not  possessing  the  processing  capabilities  often 
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assumed  in  local  area  networks.  Nonetheless,  the  network  interface  units 
used  to  connect  terminal  equipment  to  the  LAN  may  possibly  assume  some 
higher  layer  responsibilities  and  thereby  compensate  for  any  deficiencies 
in  processing  power. 

DSCS  Earth  Terminal  Definition 

To  understand  the  intercommunications  requirements  which  a  LAN  must 
fulfill,  the  physical  and  operational  characteristics  of  DSCS  terminal 
equipment  and  subsystems  have  been  studied.  From  study  of  the  DSCS  Program 
Plan  and  Transition  and  Integration  Plan,  baseline  earth  terminals  have 
been  defined  in  order  to  provide  representative  examples  of  terminal 
equipment  complements. 

The  interaction  within  the  earth  terminal  of  currently  existing  subsystems 
acts  to  define  much  of  the  terminal  intercommunications  requirements.  For 
example,  the  Digital  Communication  Subsystem  (DCSS)  encompasses  all 
terminal  baseband  equipment  which,  if  a  LAN  is  to  support  DSCS  user 
circuits,  must  be  interconnected.  Similarly,  the  DSCS  ECCM  Control 
Subsystem  (DECS)  provides  control  and  monitoring  capabilities  for  its 
associated  equipment;  a  LAN  might  possibly  be  used  to  support  the 
communication  of  control  and  status  between  DECS  equipment  and  the  DECS 
processor. 

Four  distinct  terminal  configurations  are  possible  in  DSCS  earth  terminals, 
imposing  a  variety  of  intercommunication  requirements  and  affecting  the 
design  of  any  local  area  network.  For  example,  in  some  terminals, 
equipment  of  the  DCSS  is  split  between  separate  Technical  Control  Facility 
(TCF)  and  Earth  Terminal  (ET)  installations,  requiring  some  means  of 
interconnection.  While  this  interconnection  is  currently  handled  by  the 
Interconnect  Facility,  use  of  LAN  technology  may  usurp  that  role. 

Typical  equipment  connectivities  within  the  terminals  have  been  identified 
to  characterize  equipment-to-equipment  communications  in  support  of  user 
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OSCS  TERMINAL  DEFINITION 


•  DSCS  SUBSYSTEMS 

-  DIGITAL  CO»f«JNICATIONS  SUBSYSTEM  (DCSS) 

-  DSCS  OPERATIONAL  CONTROL  SYSTEM  (DOCS) 

-  DSCS  FDMA  CONTROL  SYSTEM  (DECS) 

-  OSCS  ECCM  CONTROL  SYSTEM  (DECS) 

-  OSCS  OPERATIONAL  SUPPORT  SYSTEM  (DOSS) 

-  RF  SUBSYSTEMS  (SAMT  PROVIDES  CENTRAL  TERMINAL  CONTROL 
FACILITY) 

•  TERMINAL  SITE  CONFIGURATIONS  INTEGRATION  REQUIREMENTS 

f  TYPICAL  EQUIPMENT  CONNECTIVITIES 

-  EQUIPMENT  TO  EQUIPMENT  COtfWNICATION  TO  SUPPORT  USER 
CIRCUITS 

-  CONTROL  AND  STATUS  SIGNALS  FROM  EQUIPMENT  TO  CONTROL 
PROCESSOR(S) 

•  REPRESENTATIVE  BASELINE  TERMINALS  DEFINED  TO  EVALUATE  SUBSYSTEM 
INTERCOrtMNICATION  SOLUTIONS 

-  LIGHT  TERMINAL:  6  MBPS  AGGREGATE  USER  DATA  RATE 

-  MEDIUM  TERMINAL:  12  MBPS 

-  HEAVY  TERMINAL:  37  MBPS 
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circuits  and  equipment-to-  processor  communications  in  support  of  terminal 
control  and  status  monitoring  functions.  Based  on  these  connectivities  and 
the  available  terminal  data,  three  representative  baseline  terminals  have 
been  defined  which  reflect  light,  medium,  and  heavy  (with  respect  to 
overall  throughput)  terminals.  These  models  are  then  used  to  evaluate 
possible  intercormuni cation  solutions. 

Local  Area  Network  Options 


An  understanding  of  the  capabilities  of  local  area  networks  is  necessary  to 
assess  the  application  of  LAN  technology  in  support  of  the  identified  two 
types  of  DSCS  terminal  intercommunications.  Although  often  associated  with 
computer  communications  within  an  office,  local  area  networks  can  be 
broadly  defined  as  the  intercommunication  of  communicating  devices  within  a 
limited  physical  region.  The  wide  range  of  LAN  implementation 
possibilities  has  led  to  a  need  for  standardization.  The  IEEE  802 
committee  and  the  U.S.  Air  Force,  for  example,  have  both  defined  standards 
for  device  intercommunication  in  an  attempt  to  standardize  local  area 
network  interfaces  among  LAN  vendors. 

The  choice  of  LAN  topology,  transmission  media,  and  access  control 
technique  are  options  available  for  any  given  application.  As  depicted  by 
Figure  1-3,  bus,  ring,  star,  tree,  or  hybrid  topologies  are  possible, 
implemented  using  either  twisted  wire  pair,  coaxial  cable,  fiber-optic 
cable,  or  unbounded  transmission  media  or  a  mixture  of  media  types.  The 
choice  of  topology  might  be  based  on  some  existing  hierarchy  among  the 
devices  to  be  attached  or  reflect  reliability  considerations.  Similarly, 
the  media  chosen  is  typically  a  function  of  the  bandwidth  required  for  the 
application  and  cost  and  performance  considerations. 

Related  to  the  choice  of  topology  and  transmission  media,  the  local  area 
network's  access  control  technique  governs  the  access  of  connected  devices 
to  the  cotranuni cat ions  channel.  The  control  strategy  may,  in  most  cases,  be 
implemented  in  either  centralized  or  distributed  manner,  but  reliability  in 
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LOCAL  AREA  NETVMRK  OPTIONS 


•  CURRENT  EFFORTS  AT  STANDARDIZATION 

-  IEEE  802  COmiTTEE 

-  USAF  UNIFIED  LOCAL  AREA  NETWORK  ARCHITECTURE  (ULANA) 

•  TOPOLOGIES 

-  BUS 

-  STAR 

-  RING 

-  TREE 

-  HYBRID 

•  TRANSMISSION  MEDIA:  BANDWIDTHS.  COST 

-  TWISTED  PAIR 

-  COAXIAL  CABLE 

-  FIBER-OPTIC  CARLE 

-  UNBOUNDED  MEDIA 

•  ACCESS  CONTROL  TECHNIQUES:  CENTRALIZED  VS.  DISTRIBUTED 

-  RESERVATION 

-  SELECTION 

-  RANDOM  ACCESS 

f  ACCESS  PROTOCOL  PERFORMANCE 

-  THROUGHPUT 

-  DELAY 

-  OTHER  INDICATORS 


LOCAL  AREA  NETM)RK  ACCESS  CONTROL  TECHNIQUES 
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local  area  networks  is  generally  enhanced  if  network  control  is 
distributed.  Three  types  of  access  protocols  may  be  identified: 

•  reservation  techniques,  which  effectively  reserve  channel 
capacity  for  users  of  the  local  area  network; 

•  selection  techniques,  in  which  users  are  in  some  way  signalled 
and  thus  granted  channel  access;  and, 

•  random  access  techniques,  which  attempt  to  provide  channel  access 
to  users  upon  demand. 

Performance  capabilities  of  a  local  area  network  are  often  seen  in  terms  of 
the  performance  of  the  access  control  technique,  assessing  how  well  the 
access  protocol  can  provide  service  to  the  users  of  the  local  network. 

Such  performance  is  typically  seen  as  a  function  of  the  network  traffic 
load  and  is  quantified  in  terms  of  the  network  throughput  or,  since  most 
LAN's  support  packet-switched  communications,  the  delay  incurred  in  the 
transmission  of  a  packet.  Other  performance  indicators  are  of  course 
available,  but  throughput  and  delay  are  generally  considered  the  most 
critical  measures.  The  differences  among  the  three  access  techniques 
identified  above  may  be  discussed  in  terms  of  throughput  and  delay:  while 
random  access  techniques  generally  provide  low  packet  delays  for  low 
throughput,  they  tend  to  exhibit  ever-increasing  delays  at  the  highest 
throughput  levels;  by  comparison,  selection  and  reservation  schemes 
typically  provide  finite  delays  at  high  throughput  but  suffer  some  delay 
overhead  at  the  lowest  throughput  levels. 

Application  of  LAN  Technology 

On  the  basis  of  current  LAN  technology  and  the  assessment  of  DSCS  earth 
terminal  communications  requirements,  issues  and  concerns  regarding  the  use 
of  local  area  networks  in  the  DSCS  earth  terminals  have  been  exposed.  As 
noted,  the  interconnection  of  DSCS  terminal  equipment  involves  two  types  of 
intercommunications — in  support  of  DSCS  user  communications  and  in  support 
of  the  relay  of  control  and  status  signals.  Two  distinct  applications  of 
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APPLICATION  OF  UN  TECHNOLOGY 


TWO  DISTINCT  APPLICATIONS 

-  FULL  INTERCQIMJNICATIONS  UN  TO  SUPPORT  DEVICE 
INTERCOtMUNICATIONS  FOR  BOTH  DSCS  USER  CIRCUITS  AND 
EQUIPMENT  CONTROL  ft  STATUS  SIGNALS 

-  CONTROL  AND  STATUS  CAN  TO  SUPPORT  INTERCOMMUNICATION  OF 
EQUIPMENT  CONTROL  ft  STATUS  SIGNALS  ONLY 

FULL  INTERCOfMJNICATIONS  UN 

-  BROADBAND  BUS  PROVIDING  DEDICATED  CHANNELS 

-  REPRESENTATIVE  DESIGN  EXAMPLE  ILLUSTRATES: 

—  NETWORK  INTERFACE  UNITS 
—  UN  MANAGEMENT 
—  RELIABILITY  AND  COST 

CONTROL  AND  STATUS  UN 

-  MAY  ALLOW  PACKET-SWITCHING  TECHNIQUES  AND  USE  OF 
COtMERCIALLY  AVAIUBLE  EQUIPMENT 

-  TWO  CONNECTIVITY  STRATEGIES 

—  CONNECTION  OF  ALL  EQUIPMENT 
~  CONNECTION  OF  PROCESSORS  ONLY 


-  UN  DESIGN  INTERDEPENDENT  WITH  INTEGRATED  CONTROL  AND  STATUS 
MONITORING  CONCEPT 
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LAN  technology  have  therefore  been  considered:  first,  a  full 
intercommunications  LAN  in  support  of  both  types  of  intercommunications, 
and,  second,  a  control  and  status  LAN  in  support  of  equipment  control  and 
status  signals  only. 

Full  Intercommunications  LAN 


A  full  intercommunications  LAN,  in  addition  to  supporting  the  communication 
of  control  and  status  signals,  must  provide  reliable  circuit-switched 
communications  (both  analog  and  digital)  between  terminal  equipment  in 
support  of  DSCS  user  services.  A  full  intercommunications  LAN  must 
consequently  employ  a  reservation  access  control  technique  in  order  to 
establish  the  needed  dedicated  channels.  In  the  interests  of  reliability, 
the  access  control  technique  should  be  implemented  in  a  distributed  fashion 
to  avoid  the  possibility  of  single-point  failure.  Dedicated  channels  must 
be  provided  between  each  equipment  input  and  output  pair  composing  the  DSCS 
user  circuits'  equipment  chains  and  for  all  associated  redundant  equipment; 
the  data  rate  which  the  local  area  network  must  support  is  thus  greater 
than  the  aggregate  user  data  rate  of  the  terminal.  Bandwidth  requirements, 
then,  indicate  that  fiber-optic  cable,  broadband  coaxial  cable,  or 
unbounded  transmission  media  must  be  employed.  Unbounded  media  (radio 
frequency  or  infrared),  however,  either  pose  interference  difficulties  or 
involve  immature  technologies  and  hence  are  here  judged  inapplicable. 
Finally,  reliability  considerations  lead  to  the  choice  of  a  bus  topology 
for  the  full  intercommunications  LAN — while  other  LAN  topologies  may  be 
employed,  a  bus  is  seen  as  most  appropriate. 

Representative  Design.  Given  this  generic  understanding  of  what  a  full 
intercommunications  LAN  should  be  like,  a  representative  design  concept  is 
presented  which  is  similar  to  the  Shipboard  Communications  Area  Network 
(SCAN)  currently  under  development  by  the  Department  of  the  Navy.  This 
example — a  frequency  division  multiple  access  (FDMA)  broadband  coaxial  bus 
local  area  network — aids  in  revealing  aspects  of  a  full 
intercommunications  LAN  which  must  be  considered  no  matter  what  specific 
design  is  developed. 
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By  using  frequency  division  multiple  access  as  the  reservation  access 
control  technique,  dedicated  frequency  channels  between  equipment  input  and 
output  pairs  are  provided  in  support  of  OSCS  user  circuits.  Although 
dedicated  FDM  channels  might  also  be  used  for  the  intercoiranunication  of 
control  and  status  signals,  more  efficient  use  of  channel  capacity  is 
realized  if  one  or  more  channels  are  shared  by  the  attached  devices  through 
selection  or  random  access  packet-switching  techniques.  Control  of  the 
local  area  network  itself  is  presumed  to  be  regulated  via  such  a  packet- 
switched  FDM  channel.  Figure  1-  4  provides  an  overview  of  the  concept. 

Network  Interface  Units.  Associated  with  each  device  connected  to  the  full 
intercommunications  LAN  is  a  network  interface  unit  (NIU).  Generically, 
network  interface  units  provide  the  interface  between  a  local  area  network 
and  the  attached  device,  implementing  the  lowest  functional  levels  of  a 
layered  network  architecture.  As  an  example  of  a  possible  implementation, 
the  network  interface  units  for  the  representative  design  of  a  DSCS  earth 
terminal  full  intercommunications  LAN  are  conceived  here  as  modular  units 
composed  of  four  module  types: 

•  Fixed-frequency  cable  driver  modules  to  output  equipment  signals 
to  the  LAN; 

•  Frequency-agile  cable  receiver  modules  capable  of  accepting 
signals  from  the  LAN  and,  upon  command,  switching  from  one 
frequency  channel  to  another; 

•  Packet  service  modules  to  input  and  output  communications  on  the 
shared  packet  service  channel (s)  and,  with  its  associated 
microprocessor,  respond  to  LAN  commands  governing  network 
operations;  and, 

• 


Input/output  modules  to  serve  as  interfaces  between  the  NIU 
modules  and  each  of  the  various  attached  device  types. 
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An  Nil)  for  a  particular  piece  of  terminal  equipment  would  then  be  assembled 
from  the  appropriate  modules:  a  cable  driver  module  for  each  equipment 
output,  a  cable  receiver  module  for  each  input,  a  pacl<et  service  module  for 
the  equipment  control  and  status  ports,  and  appropriate  input/output 
modules.  The  concept  of  an  input/output  module  is  essential  to  any 
application  of  LAN  technology  in  the  DSCS  earth  terminals — terminal 
equipment  and  subsystems  currently  deployed  have  not  been  designed  for 
interconnection  via  a  LAN,  and  the  control  and  status  interfaces  in 
particular  do  not  respect  any  one  standard.  The  I/O  module  is  meant  to 
present  a  standard  interface  to  the  other  NIL)  modules  but  a  custom 
interface  to  its  associated  device.  Indeed,  if  desired,  the  I/O  module 
might  be  used  to  provide  remote  control  and  status  capabilities  for  a 
particular  piece  of  equipment  by  assuming  the  front  panel  functions.  It  is 
in  this  sense,  then,  that  higher  layers  of  a  layered  networic  architecture 
may  involve  LAN  technology. 

Other  Issues.  Issues  associated  with  a  full  intercommunications  LAN 
include  LAN  management,  the  handling  of  classified  and  unclassified  data, 
access  to  the  LAN,  and  the  impact  of  terminal  configurations.  These  issues 
are  explored  in  the  report,  revealing  considerations  that  must  be  addressed 
in  the  implementation  of  a  full  intercommunications  LAN. 

LAN  management,  for  example,  involves  the  development  of  a  management 
subsystem  to  direct  the  network  interface  units,  especially  in  switching 
among  frequency  channels  of  the  broadband  bus.  In  this  way  the  LAN 
provides  configuration  control  of  the  DSCS  earth  terminal.  Ideally,  the 
LAN  management  subsystem  would  provide  a  user-friendly  interface,  advising 
the  operator  of  correct  and  incorrect  connections,  failure  points,  and  the 
end-to-end  equipment  connectivities.  Such  a  capability  promotes  the  error- 
free  set-up  of  DSCS  user  circuits  and  reduces  reliance  on  operator 
judgement. 
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Reliability  and  Cost.  Finally,  reliability  and  cost  concerns  are 
discussed.  The  network  interface  units  represent  the  major  factors  in  both 
reliability  and  cost,  especially  if  new  product  development  is  required. 
Given  the  intercommunications  requirements  and  currently  available  LAN 
products,  a  full  intercommunications  LAN  for  the  DSCS  earth  terminals  will 
require  significant  development  effort,  although  some  use  of  existing 
products  may  be  possible.  Reliability  of  the  local  area  network  can  be 
established  through  various  design  approaches,  allowing  communications 
failures  to  be  effectively  limited  to  the  individual  connections  provided 
by  the  NIU's.  Failure  of  an  NIU  will  eliminate  the  associated  attached 
device  from  the  LAN,  disrupting  that  DSCS  user  circuit,  but  such  failure 
may  be  treated  as  equivalent  to  the  failure  of  the  device  itself —  re¬ 
configuration  of  the  LAN  connectivities  to  introduce  redundant  equipment 
will  restore  the  circuit  while  repairs  are  made. 

The  costs  of  a  full  intercommunications  LAN  per  terminal  will  be  fairly 
high,  on  the  order  of  $500,000  to  $7  million  depending  on  the  terminal  size 
and  on  the  interconnections  to  be  supported  by  the  LAN.  These  figures  are 
estimated  by  looking  at  the  interconnection  requirements  and  assuming  that 
each  NIU  module  costs  $1500,  not  including  development  costs.  Development 
costs  will  be  incurred  since  the  capabilities  necessary  for  a  full 
intercommunications  LAN  are  not  presently  commercially  available.  Since 
the  technology  involved  is  not  particularly  advanced,  however,  development 
costs  should  range  between  $100,000  and  $500,000  for  each  module. 

Control  and  Status  LAN 


A  different,  more  limited  application  of  LAN  technology  in  the  DSCS  earth 
terminals  is  possible,  supporting  only  the  control  and  status  monitoring 
functions  as  required  for  DSCS  subsystem  integration — interconnection  of 
devices  in  support  of  DSCS  user  circuits  would  not  be  supported  by  such  a 
control  and  status  LAN.  A  control  and  status  LAN  would  support  the 
communication  of  control  and  status  signals  between  DSCS  terminal  equipment 
and  the  associated  controlling  and  monitoring  processors.  The  bursty 
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nature  of  this  type  of  communications  and  the  relatively  low  data  rates 
involved  much  better  suit  the  technology  currently  provided  by  commercially 
available  local  area  networks  than  do  the  requirements  of  a  full 
intercommunications  LAN.  Cost-efficient  applications  of  LAN  technology  to 
realize  a  control  and  status  LAN  may  thus  be  feasible  using  off-the-  shelf 
components. 

The  specific  implementation  of  a  control  and  status  LAN,  however,  depends 
on  the  envisioned  operation  of  earth  terminal  control  and  monitoring 
functions  and  the  equipment-  to-processor  connectivity  desired.  Some 
existing  terminal  devices  currently  communicate  control  and  status  signals 
with  their  respective  subsystem  processors — the  processor-  to-equipment 
channel  typically  being  a  direct  cable  link.  Other  devices  may  not 
currently  possess  remote  control  and  status  capabilities  or  may  possess 
such  capabilities  yet  not  currently  be  associated  with  a 
controlling/monitoring  processor.  At  the  same  time,  some  future  DSCS  earth 
terminal  designs— in  particular,  the  Modularized  Integrated  Satellite 
Terminal  (MIST)— conceptual ize  the  presence  of  a  central  processor 
governing  operation  of  the  terminal  and  its  equipment.  The  exact  workings 
of  such  a  centralized  processor,  however,  have  not  yet  been  specified. 

In  light  of  the  above-described  state  of  affairs,  two  connectivity 
strategies  relevant  to  the  design  of  a  control  and  status  LAN  have  been 
Identified: 

•  The  control  and  status  LAN  supports  control  and  status 
communications  from  all  appropriate  terminal  equipment  and 
processors,  all  such  devices  being  connected  to  the  LAN;  or, 

•  The  control  and  status  LAN  interconnects  all  control  and  status 
monitor  processors  and  possibly  some  specific  equipment 
components — other  devices  requiring  control  and  status 
communications  interact  directly  with  their  associated 
controlling/monitoring  processor  without  use  of  the  LAN. 


RGURE  1-5:  INTERCOMMUNICATION  OF  CONTROL  AND  STATUS  DATA  FROM  Aa  TERMINAL 
EQUIPMENT  COMMUNICATION  FLOWS  AND  FUNCTIONAL  RESPONSIBIUTIES 
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The  two  connectivity  strategies  are  represented  in  Figures  1-5  and  1-6, 
respectively;  note,  however,  that  these  diagrams  illustrate  the  LAN 
connectivity  and  are  not  meant  to  suggest  the  LAN  topology. 

These  two  design  approaches  reflect  different  control  and  status  monitoring 
design  philosophies  as  well  as  different  LAN  connectivities.  The  choice  of 
control  and  status  LAN  design  should  not  be  made  in  isolation — the 
objectives  of  DSCS  earth  terminal  control  and  status  monitoring  functions 
must  be  considered  as  well. 

If  all  terminal  equipment  subject  to  remote  control  and  status  monitoring 
and  the  various  controlling/monitoring  processors  intercommunicate  via  the 
control  and  status  LAN,  then,  as  in  the  full  intercommunications  LAN,  an 
NIU  is  required  for  each  attached  device.  As  in  the  full 
intercommunications  LAN,  such  NIU's  must  suit  a  variety  of  devices  with  a 
number  of  different  interface  requirements.  This  connectivity  strategy, 
though,  lends  itself  well  to  the  goal  of  a  fully  integrated  DSCS  earth 
terminal,  especially  if  a  single  central  processor  handles  all  control  and 
monitoring  functions. 

If,  on  the  other  hand,  the  control  and  status  LAN  mostly  supports  peer-to- 
peer  communications  between  subsystem  processors  and  the  interconnection 
between  processors  and  devices  is  supported  through  other  means,  then  less 
NIU's  are  required  and  many  of  their  functions  may  be  assumed  by  the 
processors  themselves,  reducing  NIU  complexity.  Indeed,  cornmercially 
available  local  area  networks  are  typically  most  suited  for  this  sort  of 
processor-to-processor  communications,  suggesting  that  a  cost-effective 
control  and  status  LAN  may  be  developed  using  off-the-shelf  equipment. 

This  connectivity  strategy  is  evolutionary  in  the  sense  that  it  involves 
minimal  change  to  the  existing  terminal  equipment  and  will  allow  existing 
subsystem  processors  to  either  retain  their  present  roles  or  defer 
responsibility  to  some  new  central  processor.  Again,  however,  the 
envisioned  control  and  status  monitoring  system  in  an  integrated  DSCS  earth 
terminal  must  be  understood  if  an  appropriate  control  and  status  LAN  is  to 
be  designed. 
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Application  of  Digital  Switching  Technology 

In  addition  to  local  area  network  technology,  digital  switching  technology 
may  be  applied  to  provide  the  intercommunications  required  for  DSCS 
subsystem  integration.  A  digital  switch  used  as  an  electronic  patch  panel 
between  equipment  groups  provides  configuration  flexibility  and  automatic 
failover.  The  control  of  such  a  patch  panel  may  be  executed  via  a 
processor  which  provides  automated  terminal  configuration  management:  the 
configuration  of  the  electronic  patch  panel  determines  the  configuration  of 
the  terminal  equipment.  Since  the  failure  of  the  digital  switch/electronic 
patch  panel  represents  a  single  point  failure  for  the  terminal,  it  must 
support  all  signals  within  the  terminal  with  high  reliability.  Use  of  the 
Integrated  Multiplex,  Patch,  and  Test  (IMPAT) — currently  under  development 
by  Martin  Marietta  specifically  for  military  use — in  fulfilling  DSCS  earth 
terminal  interconnection  requirements  is  considered  here. 

The  IMPAT  is  a  flexible  multiplex  and  electronic  patch  device  being 
developed  for  a  variety  of  applications.  In  the  transmit  direction,  IMPAT 
accepts  user  signals,  routes  them  through  its  electronic  patch,  and  may 
perform  various  multiplexing  functions,  all  with  a  high  degree  of 
redundancy.  While  the  current  IMPAT  design  only  permits  inputs  of  less 
than  64  kbps,  future  enhancements  are  expected  to  increase  this  input 
capability  to  1.5  Mbps  or  more.  Use  of  the  IMPAT  has  been  considered  in 
terms  of  both  its  current  capability  and  assuming  future  enhancements. 

In  its  current  configuration,  the  IMPAT  can  provide  electronic  patching 
between  the  input  user  circuits  and  the  first  stage  of  multiplexers, 
replacing  the  first  stage  of  multiplexers.  Future  IMPAT  versions  may  have 
the  capability  to  accept  high  rate  inputs  to  the  electronic  patch  panel, 
allowing  multiplexer  and  other  baseband  equipment  outputs  to  be  fed  back  as 
inputs  to  the  patch  panel.  With  this  capability,  the  IMPAT  can  be  used  to 
establish  complete  baseband  equipment  chains,  eliminating  the  need  for 
external  multiplexers.  This  possible  use  of  IMPAT  assuming  such  future 
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APPLICATION  OF  DIGITAL  SWITCHING  TECHNOLOGY 


•  DIGITAL  SWITCH  (ELECTRONIC  PATCH  PANEL)  MAY  REPLACE  EXISTING 
MANUAL  PATCH  PANELS.  PROVIDING: 

-  REMOTE  CONTROL  AND  AUTOMATED  TERMINAL  CONFIGURATION 
MANAGEMENT 

-  CONFIGURATION  FLEXIBILITY 

-  AUTOMATIC  FAILOVER 

•  INTEGRATED  MULTIPLEX,  PATCH.  AND  TEST  (IMPAT)  CURRENTLY  UNDER 
DEVELOPMENT  BY  MARTIN  MARIETTA 

-  PROVIDES  ELECTRONIC  PATCH  AND  REPLACES  EXISTING  MULTIPLEXERS 

-  FUTURE  IMPAT  CAPABILITIES  MAY  ALLOW  ITS  USE  TO  ESTABLISH 
COMPLETE  BASEBAND  EQUIPMENT  CHAINS 
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addition  to  such  flexibility,  the  IMPAT  provides  a  substantial  space  and 
power  saving  in  comparison  to  the  existing  terminal  multiplexers  and  manual 
patch  panels. 

Conclusions 


This  study,  then,  has  examined  the  use  of  local  area  network  and,  to  a 
lesser  extent,  digital  switching  technology  in  the  support  of  DSCS  earth 
terminal  intercommunications.  The  information  presented  here  provides  a 
background  into  the  capabilities  of  local  area  network  technology  and  the 
needs  of  the  envisioned  application.  Issues  and  considerations  relevant  to 
the  communications  requirements  have  been  discussed,  allowing  an  informed 
assessment  of  the  available  options. 
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SECTION  2 

PROBLEM  DEFINITION 


2.1  INTRODUCTION 

Integration  of  the  DSCS  earth  tenninal  subsystems  and  equipment  supported 
by  local  area  network  (LAN)  technology  Involves  two  types  of 
Intercommunications.  This  section  defines  the  earth  terminal 
Intercommunications  problem,  followed  by  a  review  of  communications 
switching  techniques  and  the  types  of  switching  supported  by  DSCS  and 
typical  local  area  networks. 

The  section  concludes  with  a  discussion  of  layered  network  architecture 
approaches  to  system  Intercommunications  and  the  consequent  role  of  local 
area  networks  In  DSCS  earth  terminals. 

2.2  DSCS  SUBSYSTEM  INTEGRATION  REQUIREMENTS 

The  DSCS  subsystems  and  equipment  presently  In  existence  or  under 
development  allow  the  modular  construction  of  equipment  configurations 
suitable  for  various  terminal  applications.  Interconnection  of  these 
de  ices  defines  the  needed  equipment  chains;  I.e.,  the  connection  of  the 
multiplexers,  encryptors,  codecs,  modems,  up/down-converters,  and  other 
components  necessary  to  support  the  flow  of  signals  through  the  DSCS  earth 
terminal  and  thereby  establish  the  DSCS  user  circuits.  Other  Inter¬ 
connections  between  devices  allow  (or  will  allow)  computer  control  and 
status  monitoring  of  these  subsystems  to  reduce  manpower  requirements  and 
provide  Increased  system  flexibility  and  efficiency.  These  two  types  of 
Intercommunications  between  devices  are  thus  necessary  In  the  full 
Integration  of  DSCS  subsystems  and  equipment. 
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The  first  type  of  device  intercommunication — that  needed  to  support  DSCS 
communication  services — implies  the  establishment  of  dedicated  channels 
through  the  terminal  facility  to  preserve  the  transparency  of  the  OSCS 
network  with  respect  to  system  users.  Equipment  failure  or  routine 
maintenance  may  lead  to  the  re-routing  of  signals  through  different 
components,  but,  once  established,  a  DSCS  satellite  circuit  generally  is 
maintained  for  an  extended  period.  Depending  on  the  devices 
interconnected,  however,  the  transmission  rate  between  components  varies. 
For  example,  multiplexing  chains  are  often  established  as  part  of  the 
terminal  configuration,  implying  that  the  input  and  output  connections  may 
entail  much  different  transmission  rates.  Any  interconnection  technique 
must  be  able  to  accommodate  such  variability. 

The  second  type  of  device  intercommunication,  the  exchange  of  status  and/or 
control  signals,  however,  would  typically  involve  low  data  rate  bursty 
communications.  Such  control  and  status  transmissions  are  not  as  sensitive 
to  the  means  of  subsystem  intercommunication  as  are  the  intercommunications 
involved  in  supporting  DSCS  services— transparency  is  not  a  paramount 
concern  for  these  control  and  status  signals.  For  example,  delays  incurred 
as  a  result  of  the  intercommunications  between  devices  may  have  little 
effect  on  device  control  and  status  monitoring  but  may  dramatically  degrade 
the  perceived  quality  of  user  voice  circuits. 
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DSCS  SUBSYSTEM  INTERCOtIUNICATION  REQUIREHENTS 


•  INTERCQMWNICATIONS  BETWEEN  DEVICES  TO  SUPPORT  DSCS  USER  SERVICES 

-  DEDICATED  CHANNEL 

-  LOU  TO  HIGH  DATA  RATES  (<  10  MBPS) 


•  INTERCOMUNICATIONS  BETWEEN  DEVICES  FOR  EQUIPMENT  CONTROL  AND 
STATUS  MONITORING 


LOW  DATA  RATES 


R850156-b 


n.-T  WLT  wy  ^  -VTJTT  \rm  tr*  -r  f  w  *  w  - 


2.3  SWITCHING  TECHNIQUES 

The  Defense  Satellite  Communications  System  comprises  a  communications 
network,  but  so  too  may  the  interconnection  of  terminal  equipment  be 
considered  to  comprise  a  network.  From  the  OSCS  user's  point  of  vitw,  of 
course,  there  is  only  one  network,  implying  that  the  interconnection  of 
terminal  devices  must  be  made  in  a  transparent  fashion  compatible  with  the 
workings  of  the  DSCS  network  itself. 

Switching  techniques  have  traditionally  been  broadly  classified  as  circuit¬ 
switching,  message-switching,  or  packet-switching.  The  type  of  switching 
technique  employed  acts  to  define  the  character  of  a  communications 
network . 

Circuit  Switching 

In  circuit-switching,  an  end-to-end  path  is  established  through  the 
communications  network,  possibly  through  intermediate  switches.  Once 
established  through  a  call  set-up  procedure,  the  communication  path  is 
dedicated  to  the  users  until  their  session  is  complete,  after  which  the 
links  are  freed  to  be  reallocated  to  other  users.  For  short 
communications,  however,  the  call  set-up  time  may  represent  a  major 
overhead;  furthermore,  if  transmissions  are  not  continuous,  the  exclusive 
allocation  of  the  links  comprising  the  end-to-end  path  results  in  an 
inefficient  use  of  channel  capacity. 

Message  Switching 

In  message  switching,  complete  digital  messages  are  transmitted  through  the 
communication  network  to  the  end  user.  In  store-and-forward  networks,  a 
message  is  transmitted  from  node  to  node,  stored  at  each  node  until  locally 
accessed  or  relayed  (forwarded)  to  the  next  node  en  route  to  the  end 
destination.  Routing  of  a  message  may  be  performed  dynamically,  each 
intermediate  node  of  the  network  determining  the  next  link  en  route  to  the 
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SWITCHING  TECHNIQUES 


•  CIRCUIT  SWITCHING 

-  END-TO-END  DEDICATED  CHANNEL  FOR  ANALOG  AND/OR  DIGITAL 
CQMRJNICATIONS 

-  EXCLUSIVE  AND/OR  CONTINUOUS  SERVICE 

•  MESSAGE  SWITCHING 

-  TRANSMISSION  OF  COMPLETE  DIGITAL  MESSAGES 

-  STORE-AND-FORWARD  OR  BROADCAST  NETWORKS 

•  PACKET  SWITCHING 

-  DIVISION  OF  DIGITAL  MESSAGES  PROVIDES  MORE  EFFICIENT  USE  OF 
CHANNEL  CAPACITY 

-  STORE-AND-FORWARD  OR  BROADCAST  NETWORKS 

•  DSCS  PROVIDES  CIRCUIT-SWITCHED  USER  SERVICES 

•  LOCAL  AREA  NETWORKS  TYPICALLY  PROVIDE  PACKET-SWITCHED  SERVICE 
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final  destination.  The  technique  is  not  considered  acceptable  for  most 
voice  communications;  for  example,  if  speech  is  to  be  bidirectional  and 
hence  represented  by  more  than  one  digital  message,  then  the  delays 
incurred  by  each  message  may  vary  as  a  result  of  different  store-and- 
forward  routings.  Typically,  then,  message  switching  systems  are  used  for 
applications  where  the  end  communications  are  in  written  form,  as  in 
telegrams  or  correspondence. 

Packet  Switching 

Packet  switching  is  similar  to  message  switching  except  that  a  message  is 
divided  into  fixed  or  variable  length  packets.  Each  packet  contains  the 
information  needed  to  independently  route  the  data  to  its  destination;  the 
full  message  is  assembled  from  the  received  packets  by  the  end  user.  In 
this  way,  more  efficient  use  of  channel  capacity  than  achieved  with  message 
switching  may  be  realized,  especially  when  communications  are  of  a  bursty 
nature  as  is  typical  for  computer-to-computer  communications  or  character- 
by-character  terminal  communications. 

Packetized  voice  communications  are  also  possible,  however,  if  such  voice 
packets  are  handled  as  expeditiously  as  possible.  For  example,  voice 
packets  associated  with  a  particular  user  should  be  transmitted  through  the 
network  via  a  fixed  end-to-end  path  in  order  to  somewhat  standardize  the 
incurred  packet  delays  and  minimize  the  routing  overhead.  Additionally, 
other  overhead  involved  in  the  transmission  of  voice  packets  may  be 
minimized,  perhaps  by  omitting  error  correction  of  such  packets.  This 
integration  of  voice  and  data  over  a  packet-switched  network  necessarily 
involves  increased  intelligence  at  the  network  nodes,  but  is  within  the 
capabilities  of  current  technology. 

DSCS  Switching  Techniques 

Like  most  telephone  networks  throughout  the  world,  the  DSCS  network  is  a 
circuit-switched  network,  in  this  case  providing  dedicated  satellite 
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circuits  to  the  DSCS  user  community.  User  signals  are  typically  time 
division  and/or  frequency  division  multiplexed  to  form  the  DSCS  satellite 
channels.  Both  data  and  voice  traffic  are  supported  by  the  DSCS  network, 
hence  the  interconnection  of  DSCS  terminal  equipment  must  interpose  a 
minimal  traffic  delay.  The  packetization  of  data  for  communications  within 
the  terminal  thus  does  not  seem  to  be  a  reasonable  alternative — if  full 
terminal  Intercommunications  are  to  be  supported  by  local  area  network 
technology,  alternatives  consistent  with  the  end-to-end  operation  of  the 
DSCS  network  must  be  found. 
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2.4  LAYERED  NETWORK  ARCHITECTURES 

The  interconnection  of  disparate  devices  such  as  anticipated  in  the 
integration  of  OCSS  subsystems  requires  that  a  common  basis  for  meaningful 
communications  exist.  In  supporting  DSCS  communications,  most  of  the 
terminal  devices  are  already  effectively  transparent  to  the  signals;  a 
signal  is  routed,  for  example,  from  multiplexer  to  multiplexer  to  modem 
without  any  special  handling  or  processing  of  the  data  along  the  way.  In 
the  case  of  the  interchange  of  control  and  status  signals  between  DSCS 
subsystems,  however,  it  is  not  enough  that  units  be  connected  by  a  common 
medium — the  signals  presented  from  one  device  to  another  must  be 
significant  to  both.  In  other  words,  protocols  must  exist  to  enable  the 
exchange  of  meaningful  information. 

The  development  of  such  protocols  (or  the  application  of  existing  ones)  is 
further  helped  by  some  logical  division  of  responsibility.  Layered 
architectures  have  been  developed  to  fulfill  this  need,  examples  being 
IBM's  Systems  Network  Architecture  (SNA),  DEC'S  Digital  Network 
Architecture,  or  the  International  Organization  for  Standardization's  Open 
Systems  Interconnection  Reference  Model.  In  these  architectures,  the 
layers  are  considered  to  be  independent,  with  communications  between 
connected  entities  governed  by  peer-to-peer  protocols  between  corresponding 
layers,  as  suggested  in  Figure  2-1. 

The  OSI  Reference  Model 


Although  not  universally  adopted  as  a  standard,  the  Open  Systems 
Interconnection  Reference  Model  perhaps  best  serves  to  illustrate  the 
concepts  involved  in  layered  network  architectures.  Aware  of  the  need  for 
international  standardization  among  manufacturers  and  vendors  of 
information  transfer  and  processing  devices,  the  International  Organization 
for  Standardization  (ISO)  began  in  1977  to  define  a  framework  for  the 
development  of  standard  communications  protocols.  The  resulting 
International  Standard  Reference  Model  of  Open  Systems  Interconnection 
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LAYERED  NETWORK  ARCHITECTURES 


•  INTERCONNECTION  OF  DISPARATE  DEVICES  REQUIRES  STANDARDIZED  MECHANISMS 

-  INTERFACES 

-  INTERACTIONS 

•  LAYERED  ARCHITECTURE  PROVIDES  DIVISION  OF  FUNCTIONAL  AND  PROCEDURAL 
RESPONSIBILITIES 

•  CORRESPONDING  LAYERS  INTERACT  ACCORDING  TO  ESTABLISHED  PEER  PROTOCOLS 

•  INTERNATIONAL  STANDARDIZATION  ORGANIZATION'S  OPEN  SYSTEMS 
INTERCONNECTION  (OSI)  REFERENCE  MODEL  PROVIDES  FRAMEWORK  FOR 
DEVELOPMENT 

•  IEEE  PROJECT  802  COtWmEE  HAS  PROPOSED  LAN  STANDARDS  FOR  LOWER  LEVELS 


OF  THE  OSI  REFERENCE  MODEL 
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establishes  a  layered  architecture  concept  to  model  the  interconnection  of 
systems.  The  standard  is  not  meant  to  precisely  define  the  services  and 
protocols  needed  in  any  particular  application,  but  acts  to  provide  an 
international  basis  for  the  development  of  such  definitions.  From  the 
point  of  view  of  the  Reference  Model,  a  system  is  "a  set  of  one  or  more 
computers,  associated  software,  peripherals,  terminals,  human  operators, 
physical  processes,  information  transfer  means,  etc.,  that  forms  an 
autonomous  whole  capable  of  performing  information  processing  and/or 
information  transfer."  A  system  is  then  "open"  in  the  sense  that 
conformance  with  international  standards  permits  interconnection  with  all 
other  systems  also  in  compliance.  The  Open  Systems  Interconnection  (OSI) 
architecture  thus  serves  as  a  model  of  how  conforming  systems  should  appear 
externally  to  other  open  systems. 

The  OSI  architecture  models  a  network  of  interconnected  systems  as  a 
hierarchy  of  layers  of  procedural  and  functional  responsibility.  As 
suggested  by  Figure  2-1,  the  layers  span  across  individual  systems,  working 
outward  from  the  lowest  to  the  highest  layer,  building  upon  each  other. 

Each  layer  augments  the  services  provided  by  the  lower  layers  so  that, 
ultimately,  the  highest  layer  possesses  the  capability  to  administer  the 
desired  distributed  process. 

The  intersection  of  a  layer  and  a  system  may  be  seen  as  a  subsystem;  a 
layer  is  then  simply  all  subsystems  of  the  same  rank  in  the  interconnected 
network.  Cooperation  within  the  same  layer  is  governed  by  that  layer's 
protocols,  thereby  establishing  the  manner  in  which  the  services  of  lower 
layers  are  used  to  provide  the  capabilities  required  by  higher  layers. 

This  representation  of  the  layered  architecture  is  often  used  to  illustrate 
the  OSI  seven-layer  Reference  Model,  as  shown  in  Figure  2-2.  The  layered 
architecture  allows  individual  protocols  and  service  layers  to  be  replaced 
or  modified  as  needed  without  requiring  changes  in  other  parts  of  either 
the  network  or  its  individual  components. 
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figure  2-2:  THE  OSI  REFERENCE  HODEL  ARCHITECTURE 
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LAYERS  OF  THE  OSI  REFERENCE  MODEL 


•  APPLICATION  LAYER 

-  DIRECTLY  SERVES  END  USERS 

-  EXAMPLES:  RESOURCE  SHARING.  FILE  TRANSFERS,  REMOTE  FILE  ACCESS 
DATA  BASE  MANAGEMENT.  NETWORK  MANAGEMENT.  ETC. 

•  PRESENTATION  LAYER 

-  PROVIDES  COMION  REPRESENTATION  OF  INFORMATION 

-  FURNISHES  REQUIRED  TRANSFORMATIONS  BETWEEN  SYNTAXES 

-  EXAMPLE:  ISO  STANDARD  FOR  "EXTENDED  CONTROL  CHARACTERS  OF  I/O 
IMAGING  DEVICES* 

•  SESSION  LAYER 

-  SUPPORTS  PRESENTATION  LAYER  IN  ESTABLISHING  DIALOGUE 

-  ORGANIZES  AND  SYNCHRONIZES  DATA  EXCHANGE 

•  TRANSPORT  LAYER 

-  PROVIDES  END-TO-END  CONTROL  OF  A  COfMJNICATION  SESSION  ONCE  THE 
PATH  HAS  BEEN  ESTABLISHED 


EXAMPLE:  IF- IP-SPONSORED  INWG  96-1 
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LAYERS  OF  THE  OSI  REFERENCE  MODEL  (Cont'd) 


•  NETWORK  LAYER 

-  PERFORMS  ROUTING  AND  RELAY  FUNCTIONS 

-  EXAMPLE:  LEVEL  3  OF  CCITT  X.25  INTERFACE 

•  DATA  LINK  LAYER 

-  PROVIDES  FUNCTIONAL  AND  PROCEDURAL  MEANS  TO  ESTABLISH.  MAINTAIN, 
AND  RELEASE  ERROR-FREE  NODE-TO-NODE  LINKS 

—  FRAMES  MESSAGES  FOR  TRANSMISSION 
—  CHECKS  INTEGRITY  OF  RECEIVED  MESSAGES 
—  MANAGES  CHANNEL  ACCESS 
~  ENSURES  PROPER  SEQUENCE  OF  TRANSMIHED  DATA 

-  EXAMPLES:  ISO  HIGH-LEVEL  DATA  LINK  CONTROL  (HDLC).  ANSI  ADVANCED 
DATA  cam.  CONTROL  PROCEDURES  (ADCCP),  IBM  SYNCHRONOUS  DATA-LINK 
CONTROL  PROCEDURE  (SDLC) 

•  PHYSICAL  LAYER 

-  DEFINES  THE  ELECTRICAL  AND  MECHANICAL  ASPECTS  OF  INTERFACING  TO 
PHYSICAL  TRANSMISSION  MEDIA 

-  EXAMPLES:  CCITT  STANDARDS  X.21,  V.24,  V.25.  ETC. 


The  OSI  Reference  Model,  then,  establishes  a  seven-layer  architecture: 
from  highest  to  lowest,  the  Application,  Presentation,  Session,  Transport, 
Network,  Data  Link,  and  Physical  Layers.  This  seven-layer  architecture 
provides  a  framework  within  which  to  consider  the  development  of  any 
interconnection  of  devices.  The  lower  levels  of  the  ISO  Reference  Model 
are  most  pertinent  to  the  design  of  local  area  networks  and  the  problem  of 
DSCS  subsystem  intercommunications. 

DSCS  terminal  equipment  is  effectively  transparent  to  end-to-end  users  of 
the  communications  facility.  Any  local  area  network  used  to  integrate  DCSS 
equipment  must  similarly  be  transparent.  In  terms  of  the  OSI  Reference 
Model,  the  entire  Defense  Satellite  Communications  System  effectively 
comprises  a  network  of  relay  systems  connecting  the  end  users. 

If  a  local  area  network  is  used  for  the  communication  of  control  and  status 
signals  between  terminal  equipment,  then,  while  the  local  network  provides 
the  means  by  which  such  signals  are  relayed,  higher  level  protocols  must 
exist  to  facilitate  and  govern  the  interaction  of  the  communicating 
devices.  It  is  not  within  the  scope  of  this  effort  to  consider  the  nature 
of  such  higher-level  functions;  a  local  area  network  merely  provides  the 
means  to  transfer  data  among  attached  devices  with  no  guarantees  as  to  the 
correct  interpretation  of  that  data. 


R850156-C 


SECTION  3 

OSCS  TERMINAL  DEFINITION 


3.1  INTRODUCTION 

The  Defense  Satellite  Communication  System  is  a  circuit  switched  network 
providing  communications  via  a  high  capacity  Phase  Shift  Keyed  (PSK) 
Frequency  Division  Multiple  Access  (FDMA)  network  when  unstressed  and  a 
limited  capacity  Spread  Spectrum  Multiple  Access  (SSMA)  network  under 
stressed  conditions.  The  resulting  network  is  composed  of  satellite 
transponders,  earth  terminals,  and  control  elements.  Each  earth  terminal 
supports  a  portion  of  the  FDMA  and  SSMA  communication  networks  and  a 
portion  of  the  control  of  each  network. 

The  focus  of  this  study  is  the  intercommunication  of  equipment  and 
subsystems  within  the  earth  terminals  in  the  DSCS.  To  accomplish  this 
goal,  equipment  and  subsystem  configurations  which  reflect  current  and 
future  trends  in  DSCS  earth  terminal  design  must  be  identified  and 
Intercommunication  requirements  for  these  configurations  evaluated.  This 
section,  then,  identifies  terminal  equipment  and  subsystem  configuration  in 
current  and  future  earth  terminals,  and  identifies  the  communication, 
control,  and  monitoring  integration  requirements  of  subsystems  and 
associated  equipment.  Information  about  relevant  DSCS  subsystems  and  basic 
terminal  configurations  is  first  provided  as  background,  then  specific 
representative  terminal  configurations  which  can  be  used  to  evaluate 
intercommunication  solutions  are  developed  and  presented. 

This  section  begins  with  definitions  and  operational  aspects  of  the  DSCS 
subsystems,  followed  by  a  description  of  the  four  possible  logistic 
terminal  configurations.  Three  baseline  terminal  equipment  configurations 
(light,  medium,  heavy)  and  their  interactions  with  DSCS  subsystems  are  then 
outlined.  Finally,  the  integration  of  communication,  control  and  status 
signals  among  the  subsystems  is  discussed. 
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3.2  OSCS  SUBSYSTEMS 

Several  subsystems  which  are  part  of  the  DSCS  have  a  direct  impact  on  the 
integration  of  the  DSCS  earth  terminals.  The  definition  and  operational 
considerations  of  these  subsystems  is  presented  here  as  background 
information. 


Digital  Communication  Subsystem 


The  DCSS  portion  of  the  DSCS  comprises  the  baseband  equipment  located  in 
the  earth  terminals.  Its  function  in  the  baseband  to  IF  direction  is  to 
accept  various  baseband  user  signals  (data,  voice  frequency  (VF)),  digitize 
(if  necessary),  and  multiplex  them  into  higher  rate  digital  signals 
suitable  for  transmission  over  a  digital  satellite  link,  perform  the 
necessary  encryption  and  channel  coding,  and  modulate  the  resulting  high 
rate  baseband  data  to  the  IF  carrier.  A  DCSS  is  located  at  each  earth 
terminal  and  is  compatible  with  the  DCSS  located  at  any  other  terminal  in 
the  network.  The  DCSS  is  configured  so  that  a  user  circuit  from  one  earth 
terminal  to  another  passes  through  the  same  equipment  chain  at  each 
terminal;  in  this  way  the  DCSS  is  used  to  control  circuit  switching  in  the 
network.  Presently  most  of  the  DCSS  equipment  does  not  permit  remote 
monitoring  or  control;  however,  in  future  Implementations  the  DCSS 
equipment  may  be  monitored  by  a  Fault  Status  Monitor  which  will  interface 
with  the  network  control  systems,  DFCS  and  DECS.  The  location  of  the  DCSS 
in  an  earth  terminal  depends  on  the  terminal  configuration,  as  discussed  in 
Section  3.3;  it  may  be  housed  in  a  different  building  or  shelter  than  the 
earth  terminal  and/or  it  may  be  physically  split  Into  two  facilities  with 
multiplexers  in  one  facility  and  modems  in  another. 


DSCS  Operational  Control 


DOCS  has  the  responsibility  of  control  and  monitoring  of  the  overall  DSCS 
network.  It  provides  centralized  control  of  the  network  via  the  DSCS  FDMA 
Control  Subsystem  (DFCS),  the  DSCS  Electronic  Counter-Counter  Measure 
(ECCM)  Control  Subsystem  (DECS),  the  DSCS  Operational  Support  System  (DOSS) 
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DSCS  SUBSYSTEMS 


•  DIGITAL  COMHJNICATIONS  SUBSYSTEMS  (OCSS) 


•  OSCS  OPERATIONAL  CONTROL  SYSTEM  (DOCS) 


•  DSCS  FDMA  CONTROL  SYSTEM  (DECS) 


•  OSCS  ECCM  CONTROL  SYSTEM  (DECS) 


•  DSCS  OPERATIONAL  SUPPORT  SYSTEM  (DOSS) 


•  RF  SUBSYSTEMS 
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and  other  subsystems.  These  subsystems  consist  of  processing  equipment  to 
execute  control  and  monitor  status  of  equipment  in  each  terminal,  secure 
communication  channels  to  link  central  and  remote  processors,  and  central 
processors  to  evaluate  status  reports  and  generate  control  commands. 

DSCS  FDMA  Control  Subsystem  (DFCS) 

The  DFCS  is  that  portion  of  the  DOCS  which  is  responsible  for  the 
centralized  control  of  the  FDMA  DSCS  circuits.  The  DFCS  is  composed  of  a 
central  processing  unit  located  at  the  Network  Control  Terminal  (NCT)  and 
remote  processing  units  located  at  the  Network  Terminals  (NT's).  The  DFCS 
central  processor  at  the  NCT  broadcasts  control  commands  to  the  remote 
units  and  polls  the  remote  units  to  acquire  monitoring  information, 
communicating  via  a  Control  Data  Link  (CDL)  using  CDL  modems.  A  diagram  of 
the  DFCS  and  the  interaction  of  its  components  is  provided  in  Figure  3-1. 

In  each  NT,  then,  the  remote  units  interact  with  their  associated  equipment 
and  communicate  with  the  DFCS  central  processor  at  the  NCT.  The  remote 
units  execute  commands  from  the  central  unit  to  control  transmit  power  and 
monitor  receive  and  transmit  carrier  power.  Pseudo  Bit  Error  Rate  (PBER), 

IF  C/kT,  and  the  outputs  of  the  proposed  NT  Fault  Status  Monitor.  There  is 
also  a  capability  to  interface  with  the  Adaptive  Link  Power  Control  (ALPC) 
system,  an  RF  subsystem  controller. 

The  DFCS  central  processing  unit  in  the  NCT  monitors  the  NCT  status  and 
polls  the  NT's  over  the  CDL  via  frequency  division  multiple  access  channels 
to  obtain  terminal  status.  Up  to  16  NT's  can  be  polled  over  one  CDL. 
Commands  are  similarly  broadcast  to  the  NT's  over  the  CDL.  The  network 
status  monitoring  information  is  displayed  to  the  network  operator  and  is 
also  sent  to  the  DSCS  Operational  Support  System  (DOSS).  The  DOSS 
evaluates  the  status  information  and  generates  commands  to  be  sent  to  the 
remote  components,  although  commands  may  also  be  generated  by  the  network 
operator.  In  addition  to  originating  commands,  DOSS  is  used  for  database 
transfer  to  the  remote  unit  and  for  initialization  of  the  FDMA  system. 
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DSCS  ECCM  Control  Subsystem  (DECS) 

The  DECS  performs  centralized  control  and  status  monitoring  functions  for 
the  electronic  counter-counter  measure  (ECCM)  network  within  the  DSCS.  The 
DSCS  ECCM  network  supports  continuous  full  duplex  user  links  at  rates  from 
75  bps  to  1.5M  bps.  Since  satellite  resources  are  nearly  fully  utilized 
and  subject  to  stringent  availability  requirements,  it  is  important  to 
monitor  signal  quality,  satellite  loading,  and  earth  terminal  equipment 
status  and  be  able  to  control  operation  parameters  to  maintain  optimum 
resource  usage.  These  considerations  have  lead  to  the  development  of  the 
DSCS  ECCM  control  subsystem.  The  major  components  of  the  DECS  are  the 
central  component  located  at  the  Network  Control  Terminal  (NCT),  the  remote 
component  located  at  the  Network  Terminals  (NT's),  and  the  Critical  Control 
Circuits  which  provide  communication  between  the  remote  and  central  compo¬ 
nents.  The  interaction  of  these  components  is  illustrated  in  Figure  3-2. 

As  an  overview,  the  DECS  is  a  centralized  network  monitoring  and  control 
system  using  the  capabilities  of  the  AN/USC-28  modems  and  the  Critical 
Control  Circuit  (CCC)  available  in  the  DSCS.  The  DECS  accomplishes  network 
optimization  by  performing  the  following  control  and  monitoring  functions: 

•  Power  monitoring:  the  signal  strengths  of  all  USC-28 
transmissions  are  measured  by  monitoring  all  transmissions  from 
the  NT's  received  at  the  central  DECS  component  (located  at  the 
Network  Control  Terminal). 

•  Polling:  terminal  and  USC-28  status  is  transmitted  from  the  NT's 
via  return  CCC  to  the  NCT  from  all  terminals  where  it  can  be 
monitored  by  the  DECS. 

•  Network  Control:  remote  and  automatic  link  scheduling  and 
equipment  configuration  via  the  CCC  from  NCT  to  the  NT  (central 
to  remote  DECS  component). 


a  SUBSYSTEM  (DECS) 
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•  Jamming  analysis:  loop  back  of  transmitted  signals  to  the 

originating  USC-28  allows  for  measurement  of  the  satellite  power 
level.  This  calibration  permits  the  detection  of  pulsed  jammers,  etc. 

t  Interaction  with  DSCS  Operational  Support  System  (DOSS):  link 
between  DECS  and  DOSS  or  man  machine  interface  to  send  poll 
responses  and  terminal  status  from  DECS,  and  to  receive  commands 
and  configuration  control  from  the  DOSS  or  man  machine  interface. 

Each  AN/USC-28  modem  in  the  ECCM  network  consists  of  receive/transmit  (R/T) 
units  dedicated  to  supporting  the  DECS  Critical  Control  Circuits,  R/T  units 
allocated  to  support  ECCM  user  communications,  and  a  modem  control  unit.  A 
DECS  processor  is  provided  for  each  AN/USC-28  modem  which  provides  a 
control  and  monitoring  interface  to  the  modem  control  unit  as  well  as  a 
communication  interface  to  the  CCC  R/T  units  via  KG-84  encryption  units. 

The  DECS  processor  also  provides  control  and  monitoring  capabilities  for 
the  KY-883  codecs  and  the  Low  Rate  Multiplexers  (LRMs). 

At  the  Network  Control  Terminals,  the  DECS  processor  interfaces  with  the 
AN/USC-28  modem,  ECCM  baseband  equipment,  and  the  DSCS  Operational  Support 
System  to  communicate  control  and  monitoring  signals.  At  Network  Terminals 
the  DECS  processor  supports  interfaces  with  AN/USC-28  modems  and  associated 
ECCM  baseband  equipment,  including  the  Low  Rate  Multiplexers,  KY-883  codecs 
associated  with  the  Critical  Control  Circuits,  and  the  future  Fault  Status 
Monitor. 

Presently  the  DECS  is  implemented  in  the  following  manner.  ECCM  network 
control  signals  are  generated  at  the  Network  Control  Terminal  by  an 
operator  interacting  independently  with  the  DOSS.  Control  signals  are  then 
broadcast  via  the  USC-28  to  one  receiver  unit  in  each  USC-28  in  the 
network.  While  control  signals  commanding  the  USC-28  are  accepted 
automatically,  control  commands  for  other  equipment  at  the  network 
terminals  are  sent  to  a  teletype  and  actually  implemented  by  the  local 
operator.  Similarly,  USC-28  status  and  the  status  of  associated  devices 
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are  monitored  in  each  NT  by  the  DECS  processor;  other  equipment  status 
information  is  reported  hourly  by  the  network  terminal  operator  to  the 
local  DECS  processor.  Status  information  is  formatted  into  polling 
messages  at  each  network  terminal  and  continuously  broadcast  on  the  return 
critical  control  circuit;  the  USC-28  at  the  NCT  then  scans  the  return 
critical  control  circuit  for  each  NT  status  signal  and  sends  the 
information  to  the  central  DECS  control  computer  for  use  and  display. 

The  above  operational  description  of  the  ECCM  control  system  and  the  "Type 
A  Specification  For  DSCS  ECCM  Control  Subsystem"  reveal  aspects  of  the 
handling  of  control  and  status  signals  by  DECS  at  the  DSCS  earth 
terminals.  Present  equipment  generally  indicate  status  via  front  panel 
display  and/or  audio-visual  alarms  to  the  operator,  necessitating  operator 
intervention.  New  equipment  and  equipment  being  developed  (the  USC-28, 
IMPAT,  FSM,  LRM,  etc.),  on  the  other  hand,  provide  remote  status  and  alarm 
signals  designed  for  processor  interface.  Similarly,  control  of  the  new 
equipment  may  be  accomplished  via  remote  interface  to  a  command 
processor.  Presumably  these  features  will  be  available  in  all  new 
equipment.  In  addition,  an  upgrade  to  DOSS,  currently  under  development, 
will  provide  for  direct  communication  between  the  DECS  central  processor 
and  DOSS  at  the  DSCSOC's,  the  DSCS  Operations  Centers. 


DSCS  Operational  Support  System  (DOSS) 


The  DSCS  Operational  Support  System  is  the  central  element  of  the  DOCS, 
providing  the  equipment  and  software  for  the  network  managers  to  allocate 
resources  in  the  DSCS  networks  and  centralize  network  control  and  monitor¬ 
ing.  The  primary  functions  of  DOSS  are  to: 

•  Summarize  network  status  information  and  provide  reports  to  the 
network  managers; 

•  Perform  network  planning  through  the  use  of  resource  allocation 
software; 


3-9 


j  -g . 


R850156-C 


•  Produce  network  configuration  data  based  on  the  network  plan 
developed;  and, 

•  Disseminate  network  configuration  data  to  the  appropriate  DSCS 
subsystems. 

As  a  result  of  the  current  DOSS  upgrade,  DOSS  will  interface  directly  with 
DECS  for  ECCM  network  control ,  DECS  for  FOMA  network  control ,  the  DSCS 
Automatic  Spectrum  Analyzer  (DASA)  to  monitor  satellite  transmissions,  the 
Smart  Multi-Circuit  Terminal  (SMCT)  for  access  to  Terrestrial  Critical 
Control  Circuits,  the  Satellite  Configuration  Control  Element  (SCCE)  for 
satellite  payload  command,  and  the  DSCS  Operations  Center  Patch  and  Test 
Facility  (RTF)  for  inter-site  communications. 


RF  Subsystems 


The  RF  subsystems  in  DSCS  terminals  provide  up-  and  down-  conversion 
between  RF  and  IF  and  establish  transmit  and  receive  power  levels.  Current 
trends  in  earth  terminal  design  provide  control,  status  monitoring,  and 
remote  capabilities.  Such  a  design  philosophy  is  incorporated  in  the 
Modularized  Integrated  Satellite  Terminal  (MIST),  the  Ford  Aerospace  SCT-8, 
and  the  State  of  the  Art  Medium  Terminal  (SAMT).  To  complete  the  earth 
terminal  definition,  a  discussion  of  the  SAMT  as  a  typical  DSCS  RF 
subsystem  is  presented,  including  the  SAMT  interfaces  to  other  equipment  in 
the  terminal. 


The  SAMT  is  a  high-capacity,  medium-size  RF  satellite  terminal  currently 
under  development  by  Ford  Aerospace  and  Communications  Corporation.  The 
communication  flows  in  the  SAMT  are  illustrated  in  Figure  3-3:  modulated 
IF  signals  from  the  baseband  equipment  enter  the  IF  patch,  are  upconverted 
to  several  frequency  bands,  combined,  amplified,  and  transmitted  over  the 
satellite  channel;  a  similar  down-  conversion  process  is  applied  to  the 
received  signal.  The  SAMT  is  functionally  broken  into  several  subsystems 
which  are  under  the  control  of  a  central  terminal  processor. 
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The  SAMT  is  designed  for  manned  or  unmanned  operation  centralized  by  a 
control,  monitor,  and  alarm  (CMA)  subsystem.  The  CMA  subsystem  provides 
performance  monitoring,  equipment  calibration,  and  fault  isolation  allowing 
unattended  operation  and  automatic  equipment  switchover  in  the  event  of  a 
failure.  In  addition  to  controlling  SAMT  equipment,  the  SAMT  terminal 
processor  provides  control  and  status  monitoring  interfaces  for  baseband 
equipment  operating  in  the  terminal.  The  CMA  subsystem  employs  a 
distributed  architecture  with  a  central  terminal  processor  (VAX-11/730)  and 
local  controllers  associated  with  each  of  the  terminal  subsystems.  Control 
and  status  interfaces  of  the  SAMT  are  depicted  in  Figure  3-4.  The  local 
controllers  interpret  the  terminal  processor  commands  and  configure  the 
equipment  accordingly.  The  SAMT  CMA  distributed  architecture  allows 
control  from  the  terminal  processor  as  well  as  from  the  local  controllers 
and  the  equipment  front  panels.  The  local  controllers  are  implemented  as 
cards  in  the  equipment  chassis  with  RS-232-C  interfaces  to  the  terminal 
processor.  Although  the  local  controllers  include  circuitry  unique  to  the 
specific  equipment  they  control,  they  are  designed  to  provide  a  degree  of 
hardware  and  software  commonality. 
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3.3  TERMINAL  CONFIGURATIONS 

Each  earth  terminal  in  the  OSCS  network  performs  communication  processing 
to  prepare  user  signals  for  transmission  over  the  satellite  channel  and  to 
extract  user  signals  from  the  received  satellite  signal.  The  way  in  which 
the  communication  processing  is  performed  will  determine  to  an  extent  the 
way  in  which  the  communications  equipment  is  integrated  in  the  earth 
terminals.  Processing  responsibility  in  DSCS  earth  terminals  is  divided 
among  the  Technical  Control  Facility  (TCF),  the  Digital  Communications 
Subsystem  (DCSS),  and  the  Link  Terminal.  In  some  cases  the  Link  Terminal 
and  TCF  may  be  physically  separated;  for  these  cases  an  Interconnect 
Facility  (ICF)  is  provided  to  allow  transparent  communication  between  the 
Link  Terminal  and  the  TCF.  The  Technical  Control  Facility  provides  an 
interface  to  OSCS  users,  performing  any  necessary  signal  conditioning 
required  to  produce  a  DSCS-compatible  signal.  The  DCSS  accepts  these 
signals  and  performs  multiplexing,  coding,  encryption,  and  modulation  to 
produce  the  IF  signal  suitable  for  transmission  through  a  DSCS  satellite 
channel.  The  Link  Terminal  provides  the  facilities  for  transmission  and 
reception  of  the  RF  satellite  channels.  Note  that  OSCS  nomenclature 
typically  uses  the  term  "Earth  Terminal"  or  "ET"  to  refer  to  the  DCSS  and 
Link  Terminal  capabilities  in  order  to  distinguish  those  services  from  the 
user  interface  provided  by  the  TCF. 

There  are  four  different  cases  of  earth  station  configuration,  as  shown  in 
Figure  3-5.  The  configuration  of  a  given  earth  terminal  will  depend  on  the 
geographical  and  logistical  characteristics  of  the  site.  The  differences 
in  each  case  are  the  location  of  DCSS  processing  (in  the  TCF  or  ET 
facilities  or  both)  and  the  link  employed  by  the  Interconnect  Facility.  In 
Case  I,  the  TCF  and  ET  are  closely  situated  in  two  separate  buildings.  The 
ICF  consists  of  baseband  coaxial  cables  and  DCSS  processing  is  located  in 
the  earth  terminal.  In  Case  II,  the  TCF  and  ET  are  separated  by  a  distance 
requiring  microwave  or  fiber  optic  communication  in  the  ICF.  DCSS  process¬ 
ing  responsibility  is  split,  with  modulation  in  the  ET,  and  multiplexing 
and  coding  located  at  the  TCF.  In  Case  III,  the  TCF  and  ET  are  located  in 


R850156-C 


the  same  building/shelter;  the  interconnection  is  provided  by  baseband 
cable  and  all  DCSS  processing  is  performed  in  the  ET.  The  configuration  of 
Case  IV  pertains  to  closely  located  TCP  and  ET  in  two  separate  buildings 
interconnected  by  baseband  cable  or  fiber  optics.  DCSS  processing  respons¬ 
ibility  is  split  between  the  TCP  and  the  ET.  In  cases  where  the  DCSS 
signal  processing  is  split  between  two  locations  some  type  of  communica¬ 
tions  resource  (ICP  or  other)  must  be  provided  to  support  control  and 
status  monitoring  for  full  terminal  integration. 
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•  CASE  II 

-  OCSS  FUNCTIONS  ARE  SPLIT  BETWEEN  TCF  AND  ET 

-  DIVISION  OF  OCSS  IS  SITE-DEPENDENT 

-  ICF  CONNECTS  THE  TWO  PARTS  OF  DCSS  VIA  LINE  OF  SITE 
COfMJNICATIONS  (UP  TO  SEVERAL  MILES) 

I  CASE  III 

-  TCF  AND  ET  ARE  CO-LOCATED,  WITH  DCSS  AS  PART  OF  ET 
I  CASE  IV 

-  DCSS  FUNCTIONS  ARE  SPLIT  AS  IN  CASE  II 


ICF  USES  CABLE  OVER  SHORT  DISTANCES  (BETWEEN  BUILDINGS) 


TECHNICAL  CONTROL  FACILITY 
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3.4  EQUIPMENT  CONFIGURATIONS 

The  previous  sections  discuss  the  responsibility  of  various  subsystems  in 
OSCS.  In  order  to  investigate  the  intercommunication  and  integration  needs 
of  DSCS  terminal  equipment  and  subsystems,  equipment  configurations  and  the 
associated  connectivities  and  interfaces  among  subsystems  and  equipment 
must  be  identified.  The  equipment  configurations  of  the  Digital 
Communications  Subsystem  in  the  DSCS  terminals  are  emphasized  here.  Since 
terminal  configurations  vary  from  terminal  to  terminal  based  on  geography, 
loading,  priority,  etc.,  the  generic  equipment  configuration  of  Figure  3-6 
will  serve  as  a  basis.  In  this  configuration  three  basic  equipment  groups 
are  identified —  multiplexer,  modem,  and  RF — with  the  multiplexer  group 
and  modem  group  detailed  further  in  Figures  3-7  and  3-8,  respectively. 

In  the  transmit  direction,  user  signals  typically  arrive  from  the  TCF  via  a 
main  distribution  frame  from  which  they  are  routed  to  multiplexing,  encryp¬ 
tion,  and  coding  equipment.  The  output  of  equipment  in  this  group  is  fed 
into  the  modem  inputs;  the  modulated  IF  output  is  then  sent  to  the  RF 
equipment  for  upconversion  and  transmission.  In  addition  to  these  three 
groups.  Figure  3-6  shows  a  control  and  status  monitoring  capability 
providing  control  and  monitoring  access  to  equipment  in  the  terminal. 

The  multiplexer  group  of  equipment  is  typified  by  the  configuration  of 
Figure  3-7.  Low  rate  user  signals  (<=64  kbps)  are  time  division 
multiplexed  into  several  higher  rate  signals  for  modulation  to  IF.  The 
AN/FCC-98  low  rate  multiplexer  accepts  24  voice  or  data  inputs  each  up  to 
64  kbps  while  its  maximum  output  rate  is  1544  kbps;  the  AN/GSC-  24 
multiplexer  accepts  inputs  of  rates  from  50  bps  to  3  Mbps  and  produces  an 
output  limited  to  a  rate  of  10  Mbps.  These  particular  multiplexers  are 
not  equipped  to  generate  and/or  accept  status  and  control  signals;  however, 
other  DSCS  earth  terminal  multiplexers  such  as  the  Low  Rate  Multiplexer 
(LRM)  and  the  future  Integrated  Multiplex,  Patch,  and  Test  (IMPAT)  do  pro¬ 
vide  control  and  monitoring  access  and,  if  full  terminal  integration  is  to 
be  realized,  require  connectivity  to  a  control  and  monitoring  capability. 
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A  similar  typical  configuration  is  shown  in  Figure  3-8  for  the  modem  group 
of  equipment.  Two  modem  types  corresponding  to  the  Electronic  Counter- 
Counter  Measure  network  and  the  FDMA  network  are  employed  in  the 
terminal.  The  AN/USC-28  spread  spectrum  modem  is  used  for  ECCM  user 
communications  as  well  as  ECCM  control  and  monitoring  communications  and 
interfaces  directly  with  the  processing  unit  of  the  DSCS  ECCM  Control 
Subsystem;  the  AN/USC-28  modem  contains  up  to  15  receive/transmit  units 
which  modulate  a  70/700  MHz  IF  carrier  with  rates  up  to  2.5  Mbps.  The  MD- 
XXXX  modem  is  a  non-ECCM  BPSK/QPSK  modem  currently  in  development;  each 
receive/transmit  unit  of  the  MD-XXXX  modulates  the  IF  carrier  with  signals 
of  rates  from  16  kbps  to  20  Mbps  (QPSK,  no  coding).  A  master  controller 
module  within  the  MD-XXXX  is  responsible  for  up  to  16  receive/transmit 
modules  and  provides  automatic  external  control  and  monitoring  capabili¬ 
ties.  The  AN/USL-28  and  MD-XXXX  are  also  compatible  with  the  coding/- 
decoding  equipment  (KY-801,  KY-883)  at  all  modem  rates.  The  KY-883  codec 
provides  a  control  and  status  monitoring  interface  to  the  DECS  processor 
associated  with  the  ECCM  modem  with  which  it  operates. 

In  the  design  of  earth  terminals  it  is  desirable  to  allow  for  a  measure  of 
fault  tolerance  achievable  through  the  use  of  redundant  equipment  and 
switching  capabilities.  At  present,  redundant  equipment  is  manually 
switched  on-line  via  patch  panel  when  a  terminal  element  fails.  In  future 
configurations  it  may  bje  desirable  to  employ  electronic  patching  which  can 
be  automatically  controlled  when  an  equipment  failure  is  detected. 
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3.5  BASELINE  TERMINAL  CONFIGURATIONS 


Given  that  the  equipment  configuration  varies  from  terminal  to  terminal, 
three  baseline  terminal  configurations  to  cover  three  ranges  of  loading  (in 
terms  of  aggregate  user  data  rate)  are  defined  in  order  to  evaluate  DSCS 
subsystem  intercommunication  solutions.  Each  configuration  is  based  on 
the  information  presented  in  the  previous  sections  regarding  communications 
connectivities,  interfaces  to  control  subsystems  (DECS  and  DFCS),  and  the 
DSCS  user  community.  These  terminal  configurations  are  then  used  as  a 
testbed  for  possible  intercommunication  solutions. 

Requirements  for  future  DoD  earth  terminals  assume  an  integrated  design 
philosophy  and  call  for: 

•  Standardization  of  equipment  and  associated  interfaces  to  reduce 
life  cycle  costs; 

•  Centralized  configuration  control  and  performance  and  status 
monitoring; 


Fault  detection  and  failover  capabilities;  and. 


Remote  control  capabilitfes. 


Such  features  are  inherent  in  the  proposed  Modularized  Integrated  Satellite 
Terminal  (MIST)  concept;  therefore,  the  MIST  is  used  in  this  study  as  the 
baseline  configuration  for  a  light  terminal  (aggregate  user  data  rate  less 
than  10  Mbps).  Figure  3-9  shows  the  communications,  control  and  monitoring 
connectivities  for  the  light  baseline  terminal.  User  signal  and  equipment 
data  are  presented  for  all  three  baseline  configurations  in  Tables  3-1  and 
3-2,  respectively.  Since  the  actual  configuration  of  each  terminal  varies. 
Figure  3-9  suffices  to  illustrate  the  connectivities  present  in  medium  and 
heavy  terminals  as  well  as  in  light  terminals,  although  the  number  of 
devices  will,  of  course,  be  different. 
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Communications  connectivity  within  the  terminal  is  best  characterized  by 
following  a  user  circuit  in  the  transmit  direction  from  the  main  distribu¬ 
tion  frame  to  the  IF  patch  panel.  The  user  signal  follows  a  circuit  from 
the  main  distribution  frame  either  directly  to  a  modem  (for  high  rate  and 
some  ECCM  users)  or  to  a  group  of  multiplexers  where  it  is  combined  with 
other  signals  to  form  a  higher  rate  signal.  This  high  rate  signal  is  then 
routed  either  to  another  multiplexer  or  to  a  receive/transmit  (R/T)  unit  of 
a  modem.  The  data  signal  is  error-correction  coded  and  modulated  to  IF, 
then  routed  through  the  IF  patch  panel  to  an  upconverter  where  it  is 
allocated  one  of  the  satellite  channels  and  transmitted  at  RF.  Circuit 
switching  in  the  DSCS  network  is  currently  accomplished  by  switching  the 
user  circuit,  via  manual  patch  panels,  to  an  alternate  multiplexer  whose 
output  is  routed  to  the  desired  location.  Switching  of  entire  groups  of 
circuits  is  accomplished  by  switching  multiplexer  outputs  via  the  patch 
panel.  In  the  event  of  an  equipment  failure,  patch  panels  are  also  used  to 
work  around  failed  equipment. 

Increased  requirements  for  controllability,  status  monitoring  and  fault 
monitoring  have  created  connectivity  requirements  between  equipment  and 
control  and  status  monitoring  capabilities  in  DSCS  network  terminals.  In 
addition  to  communications  connectivities.  Figure  3-9  depicts  typical 
equipment  control  and  status  connectivities.  Underlying  the  connectivity 
for  control  and  status  signals  in  the  terminals  is  the  division  of  control 
and  monitoring  responsibility  among  the  DSCS  control  subsystems,  DECS, 

DECS,  FSM,  etc.  The  DECS  processor  allows  for  control  and  status 
interfaces  to  the  Low  Rate  Multiplexer,  AN/USC-28  modem,  KY-833  codecs  and 
the  terminal  Fault  Status  Monitor  (FSM).  The  DECS  processor  also  allows 
secure  communication  of  terminal  control  and  status  data  over  the  Critical 
Control  Circuits  to  the  Network  Control  Terminals.  The  DFCS  processor 
allows  for  interfaces  to  the  FDMA  modem,  carrier  monitor,  a  performance 
monitor  (for  PEER),  the  terminal  fault  status  monitor,  and  also  communi¬ 
cates  to  the  central  DFCS  processor  at  the  Network  Control  Terminal  over 
the  Control  Data  Link. 
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Much  of  the  equipment  currently  installed  in  the  earth  terminals  are  not 
designed  to  interface  with  a  central  control  and  monitor  system  and  as  a 
result  do  not  provide  any  standard  control  and  monitoring  access.  For 
example,  the  multiplexers  not  mentioned  above  (FCC-98,  GSC-24)  currently 
provide  relay  switch  alarms  and  are  configurable  from  their  front  panel 
only.  Multiplexer  equipment  currently  being  developed  (e.g.,  IMPAT)  do 
provide  control  and  status  interfaces  which  may  be  exploited  for  terminal 
monitoring  (via  the  FSM)  and  configuration  control.  A  control  subsystem 
for  these  multiplexers,  however,  has  not  been  identified.  The  MIST 
specification  calls  for  a  centralized  control,  monitor,  and  alarm  subsystem 
whose  interaction  with  DECS  and  OFCS  is  unclear.  Similarly,  the  SAMT  RF 
terminal  contains  a  central  processor  which  allows  for  control  and  status 
interfaces  to  baseband  equipment  which  is  not  explicitly  included  in  the 
SAMT. 

The  handling  of  classified  data  in  the  terminals  is  an  issue  which  affects 
the  interconnection  of  equipment.  Communication  connectivities,  with  the 
exception  of  the  CCC  and  CDL  lines,  are  assumed  to  be  previously  encrypted 
and  considered  black.  Processors  containing  network  configuration  data; 
i.e.,  DECS,  are  considered  red,  while  control  and  status  connectivities  to 
equipment  may  be  black  if  they  are  properly  protected  with  a  Line  Guardian 
Unit  to  prevent  classified  information  from  the  processor  from  entering  a 
black  area. 


R850156-a 


SECTION  4 

LOCAL  AREA  NETWORK  OPTIONS 

4.1  INTRODUCTION 

This  section  serves  to  provide  some  background  on  local  area  networks  and 
acts  as  a  basis  for  this  study's  discussion  of  the  use  of  LAN  technology  in 
DSCS  earth  terminals.  A  local  area  network  may  be  broadly  defined  as  the 
interconnection  of  communicating  devices  within  a  limited  physical  region, 
on  the  order  of  a  few  square  kilometers.  As  a  consequence  of  their  role  in 
the  emergence  of  the  "electronic  office,"  local  area  networks  are  often 
associated  with  on-site  packet-switched  computer  communications.  Even  that 
description,  however,  is  overly  restrictive  given  the  wide  variety  of  LAN 
designs  that  exist,  both  commercially  and  experimentally.  The  many 
variables  involved  may  be  seen  in  terms  of  the  available  local  area  network 
options  of  topology,  transmission  media,  and  access  control  techniques 
outlined  in  this  section. 

The  diversity  possible  among  local  area  networks,  however,  has  lead  to 
confusion  in  the  marketplace.  Appendix  B  tabulates  a  number  of  LAN 
manufacturers  and  their  products,  illustrating  the  many  LAN  technologies 
currently  available.  To  promote  coordination  within  the  computer  and 
communications  industry,  the  IEEE  802  committee  issued  in  July,  1981  its 
first  draft  of  a  proposed  local  network  standard  governing  the  two  lowest 
layers  of  the  OSI  architecture.  After  several  years  of  refinement,  the 
standards  have  now  been  approved  and  adopted  by  many  major  equipment 
vendors.  The  US  Department  of  Defense  has  also  made  efforts  to  standardize 
local  area  networks,  one  example  being  the  Unified  Local  Area  Network 
Architecture  (ULANA)  of  the  Air  Force. 
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802.1 

802.2 

802.3 

802.4 

802.5 

802.6 


IEEE  802  COmiTTEE  LAN  STANDARD  DEVELOPMENT 

802  COMUHEE  LAN  STANDARDS  AND  THE  OSI  REFERENCE  MODEL 

LOGICAL  LINK  CONTROL 

CSMA/CD  ACCESS  METHOD  AND  PHYSICAL  LAYER  SPECIFICATION 

TOKEN-PASSING  8US  ACCESS  METHOD  AND  PHYSICAL  LAYER  SPECIFICATION 

TOKEN-PASSING  RING  ACCESS  METHOD  AND  PHYSICAL  LAYER  SPECIFICATION 

METROPOLITAN  AREA  NETWORK  ACCESS  METHOD  AND  PHYSICAL  LAYER 


SPECIFICATION 


REFERENCE  MODEL  IEEE  802  MODEL  IMPLEMENTATION 
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commercial  or  light  industrial  applications.  The  standards  pointedly  do 
not  address  issues  such  as  computer-controlled  voice/data  Private  Branch 
Exchange  (PBX)  networks,  military  local  networks,  and  real-time,  high 
reliability  industrial  applications  such  as  process  control.  Nonetheless, 
the  IEEE  802  committee's  efforts  in  providing  standards  have  allowed  many 
manufacturers  to  move  with  confidence  in  presenting  local  area  networks  to 
the  commercial  marketplace. 

The  IEEE  802  committee  LAN  standards  define  a  shared  channel  configuration, 
with  low  cost  and  ease  of  incremental  network  expansion  considered  to  be 
design  goals.  The  IEEE  standard  subdivides  the  OSI  Data  Link  Layer  into 
two  layers,  the  Logical  Link  Control  and  Media  Access  Control  Layers,  as 
shown  in  Figure  4-1.  The  Logical  Link  Control  layer  draws  upon  the 
Asynchronous  Balanced  Mode  link  control  procedures  specified  by  ISO  6256- 
1979  and  ANSI  X3. 66-1979  to  define  a  standardized  frame  format  and  error 
recovery  procedure.  The  Media  Access  Control  Layer  defines  the  mechanisms 
by  which  the  shared  channel  is  successfully  utilized  by  the  stations 
composing  the  network.  Figure  4-1  illustrates  how  the  responsibilities  of 
the  two  IEEE  802  layers  may  be  arbitrarily  divided  between  the  Network 
Interface  unit  and  the  attached  device,  depending  on  the  capabilities  of 
the  device  and  the  specific  implementation.  Since  throughput  and  message 
delay  characteristics  are  dependent  upon  the  employed  channel  access 
protocol,  the  IEEE  802  committee  has  developed  proposed  standards  for  two 
access  control  techniques,  token-passing  and  carrier  sense  multiple  access 
with  collision  detection  (CSMA-CO). 

The  IEEE  specification  also  applies  to  the  OSI  Physical  Layer  and  the 
physical  medium  itself  (which  is  beyond  the  scope  of  the  OSI  Reference 
Model).  Characteristics  of  a  physical  interface  are  thus  defined  which 
allow  it  to  be  independently  implemented  by  different  vendors  and  still 
prove  compatible.  Currently,  the  standards  define  specific  functional, 
electrical,  and  mechanical  characteristics  of  a  baseband  coaxial  cable 
system  supporting  CSMA-CD  and  a  coaxial  cable  system  supporting  a  "token¬ 
passing  single  channel  phase-continuous  frequency  shift  keying  (FSK)  bus"; 
other  media  are  to  be  standardized  at  some  future  date. 
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Air  Force  Unified  Local  Area  Network  Architecture 

The  Air  Force  Unified  Local  Area  Network  Architecture  (ULANA)  is  a  subset 
of  the  Air  Force  Information  System  Architecture  (AFISA).  The  goal  of  the 
Information  System  Architecture  is  to  provide  a  basis  on  which  to  guide 
both  the  near-  and  long-term  design  of  individual  and  integrated 
information  systems.  In  that  context,  ULANA  is  intended  to  provide  the 
architecture  and  hardware/software  needed  to  implement  the  Air  Force's 
local  area  networks. 

ULANA  is  meant  to  support  information  transfer  among  devices  (as  opposed 
to,  say,  process  control).  The  ULANA  architecture  is  therefore  predicated 
on  several  design  principles:  1),  a  layered  architecture  is  observed,  in 
the  spirit  of  the  OSI  Reference  Model  and  the  DOD  Protocol  Reference  Model; 
2),  ULANA  is  to  be  fully  interoperable  with  the  DOD  long  haul  network,  the 
Defense  Data  Network  (DDN);  and  3),  almost  all  network  communications 
functions  are  to  be  distributed  in  network  interface  units  which  interface 
and  attach  the  subscriber  devices  to  the  local  area  network. 

As  a  consequence  of  its  goals  and  objectives,  the  ULANA  effort  concerns 
itself  mostly  with  the  interfacing  of  the  local  area  network  to  subscriber 
devices  and  to  external  networks  such  as  DON  or  public  packet-switching 
networks.  The  employed  media  access  control  techniques— the  main  concern 
of  the  IEEE  802  committee — are  not  a  focus  of  ULANA,  although  their 
importance  is  recognized.  ULANA  thus  attempts  to  standardize  the  Air 
Force's  use  of  local  area  networks  by  defining  and  contracting  standardized 
equipment. 

Local  Area  Networks  Versus  Computer  Buses 

The  broad  definition  of  a  local  area  network  given  above  might  also  be 
taken  to  apply  to  the  bus  structure  of  a  computer.  Indeed,  local  area 
networks  may  possess  a  bus  topology,  yet  such  a  network  would  not  be 
considered  a  computer  bus.  The  distinctions  are  perhaps  subtle,  hinging  on 
the  notion  of  a  local  area  network  as  the  interconnection  of  a  number  of 
autonomous  stations. 
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The  management  and  control  strategies  of  a  network,  for  example,  are  far 
more  defensive  than  the  equivalent  strategies  of  a  bus  are  required  to 
be.  Failure  of  a  connected  device  on  a  computer  bus  structure  generally 
leads  to  failure  of  the  system;  a  network,  however,  should  exhibit  more 
fault-tolerant  behavior.  If  insufficient  capacity  is  available  on  a  bus, 
hardware  or  software  reconfigurations  are  typically  necessary;  a  network 
will  instead  attempt  to  gracefully  mediate  such  intense  traffic  demands. 
Local  area  networks  are  also  more  general  than  computer  buses.  A  network 
usually  supports  the  transmission  of  variable  size  messages,  while  a  bus 
often  handles  only  single,  fixed-size  words.  The  interfaces  provided  by  a 
network  are  often  generalized  to  accommodate  a  wide  variety  of  devices;  a 
computer  bus  typically  has  a  specialized  interface  directed  towards  the 
addressing  and  control  architecture  of  a  particular  device. 

The  bus  structure  defined  by  the  IEEE-488  standard  illustrates  the 
distinctions  between  local  area  networks  and  computer  buses.  The  IEEE-488 
standard  defines  a  general  byte  serial  bit  parallel  interface  capable  of 
interconnecting  a  variety  of  instruments  and  computers  and  has  been 
implemented  in  several  brand  versions  as,  for  example,  HP-IB,  GPIB,  and  the 
IEEE  Instrumentation  Bus.  The  HP-IB  provides  a  maximum  supported  data  rate 
of  1  Mbps  with  the  total  transmission  path  lengths  restricted  to  less  than 
20  meters  or  2  meters  per  device,  whichever  is  less.  By  interconnecting 
devices  with  such  a  level  of  autonomy,  the  IEEE-488  bus  resembles  a  local 
area  network.  The  bus  does  not,  however,  support  more  than  15  devices  in 
one  contiguous  bus  nor  does  its  addressing  structure  readily  allow  it  to  be 
extended.  Furthermore,  the  IEEE-488  bus  is  not  as  defensive  as  a  local 
area  network  would  be:  the  system  designer  must  insure  that  the  capacity 
of  the  bus  is  not  exceeded  and  must  detect  and  insure  the  removal  of  faulty 
connections  which  disable  the  bus.  With  such  distinctions  in  mind,  the 
design  of  a  local  area  network  involves  consideration  of  various  options 
concerning  the  network  topology,  transmission  medium,  and  access  control 
technique. 
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4.2  LOCAL  AREA  NETWORK  TOPOLOGIES 

The  interconnection  of  devices  in  a  local  area  network  may  be  configured  in 
several  different  topologies,  as  shown  in  Figure  4-2;  bus,  star,  ring,  and 
tree  topologies  are  typical,  although  hybrids  (mesh  topologies)  are 
possible.  The  choice  of  topology  reflects  various  aspects  of  the  network; 
for  example,  whether  a  central  controller  is  present,  whether  there  exists 
a  logical  hierarchy  of  network  users,  etc.  The  selection  of  network 
topology  may  also  be  intimately  related  to  the  choice  of  the  network  access 
control  mechanism;  indeed,  the  operation  of  some  access  protocols  relies 
upon  specific  network  organizations. 

Local  area  network  topologies  may  be  divided  into  two  main  classes, 
broadcast  and  sequential.  In  a  broadcast  configuration,  a  transmission  by 
one  station  is  received  by  all  stations  of  the  network.  In  a  sequential 
configuration,  point-to-point  transmissions  between  stations  define  the 
communications  flow. 

Broadcast  topologies  intrinsically  require  that  each  station  transceiver  be 
able  to  handle  a  wide  range  of  signal  strengths.  A  minimum  signal  strength 
on  a  broadcast  topology  is  generally  established  by  limiting  both  the 
length  of  the  transmission  media  and  the  number  of  connections.  If  the 
network  is  to  exceed  these  limits,  amplifiers  or  repeaters  are  often  used 
to  maintain  the  necessary  levels. 

In  a  broadcast  configuration,  only  one  station  may  successfully  use  the 
channel  at  a  time.  Access  control  protocols  must  therefore  regulate  which 
station  may  assume  control  of  the  shared  channel.  The  maximum  end-to-end 
propagation  delay  of  the  broadcast  channel  imposes  an  implicit  delay 
overhead,  however,  which  is  often  on  the  order  of  hundreds  of  bit  times. 

To  minimize  the  impact  of  such  overhead,  broadcast  local  area  networks 
typically  specify  a  minimum  packet  size  which  may  be  transmitted. 
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LOCAL  AREA  NETWORK  OPTIONS;  TOPOLOGIES 

•  BUS 

-  BROADCAST  OPERATION  WHEREIN  A  TRANSMISSION  BY  ONE  STATION  IS 
RECEIVED  BY  ALL  STATIONS  OF  THE  NETM)RK 

-  FAILURE  OF  A  STATION  DOES  NOT  AFFECT  OPERATION  OF  NETWRK 

•  STAR 

-  CENTRAL  NODE  LINKING  ALL  OTHER  STATIONS 

-  FAILURE  OF  CENTRAL  NODE  GENERALLY  IMPLIES  NETWORK  FAILURE 

t  RING 

-  SEQUENTIAL  OPERATION,  DATA  RELAYED  FROM  STATION  TO  STATION 

-  NETWORK  REDUNDANCY  REQUIRED  TO  REDUCE  RISK  OF  NETWORK  FAILURE 
UPON  STATION  FAILURE 

•  TREE:  CENTRALIZED,  DECENTRALIZED,  OR  HYBRID  OPERATION 


•  HYBRID  TOPOLOGIES 
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Sequential  configurations,  as  compared  to  broadcast  configurations,  do  not 
place  such  stringent  requirements  on  the  performance  of  station 
transceivers  since  only  point-to-point  connections  need  be  supported. 
Consequently,  different  transmission  media  between  stations  may  even  be 
employed  to  constitute  the  sequential  network. 

Bus 

A  bus  topology  implies  a  broadcast  configuration  and  is  one  of  the  most 
common  of  local  area  network  topologies.  Bus  topologies  are  characterized 
by  standardized  connection  interfaces  and  high  reliability.  Typically, 
stations  attach  to  the  network  transmission  medium  in  such  a  way  that  the 
failure  of  any  station  will  not  affect  operation  of  the  network.  In  the 
case  of  coaxial  cable  bus  networks,  for  example,  stations  may  be  attached 
to  the  cable  with  taps  which  do  not  require  physically  cutting  the  cable. 

A  bus  topology  thus  often  implies  a  reliable  network,  unaffected  by 
individual  station  failures.  Physical  damage  to  the  bus,  of  course,  will 
likely  disrupt  the  network  unless  a  duplicate  bus  is  installed  as  backup. 

A  bus  topology,  however,  does  have  several  disadvantages.  For  example, 
every  station  must  be  able  to  send  and  receive  data  at  the  full  speed  of 
the  bus,  possibly  a  much  greater  data  rate  than  is  required.  Every  station 
must  also  transmit  with  enough  signal  power  to  be  received  at  the  most 
distant  station.  And  since  all  network  stations  observe  all  network 
traffic,  a  bus  is  inherently  non-secure;  sensitive  data  must  be  encrypted 
or  alternate  transmission  means  must  be  provided  for  such  data. 

Tree 


A  tree  configuration  may  be  seen  as  the  interconnection  of  several  buses 
joined  by  active  repeaters  or  by  passive  splitters.  Such  an  extended  bus 
effectively  defines  a  rootless  branching  tree  topology.  In  broadband 
coaxial  cable  local  area  networks,  a  rooted  tree  topology  is  often  used 
where  the  root  is  defined  by  the  cable's  active  head  end.  In  such  cases. 


R850156-a 


the  tree  is  vulnerable  to  failure  of  the  equipment  at  the  root  unless 
adequate  redundancy  is  provided.  A  tree  topology  may  also  be  used  when 
some  hierarchy  among  stations  is  to  be  established.  Hierarchical  groupings 
may  be  desired  for  purposes  of  the  network  itself  (e.g.,  in  order  to 
implement  the  access  control  algorithm)  or  to  reflect  functional 
characteristics  of  the  attached  stations. 

Star 

A  star  topology  implies  a  central  node  to  which  all  other  stations  are 
linked;  it  may  be  seen  as  a  rooted  tree  topology  in  which  a  branch  extends 
from  the  root  to  all  network  stations.  A  central  computer  which  cyclically 
polls  all  attached  stations  or  a  Private  Branch  Exchange  (PBX)  local  area 
network  are  examples  of  such  a  topology.  Failure  of  the  central  node, 
however,  typically  implies  failure  of  the  entire  network  unless  provision 
is  made  for  such  a  contingency.  Additionally,  if  cabling  is  used  to 
support  a  star  topology  local  area  network,  then  new  cabling  must  be 
installed  for  every  new  station  added  to  the  network  and,  generally,  much 
more  cabling  is  required  than  in  an  equivalent  bus  or  ring  network. 

Ring 

In  a  ring  topology,  stations  sequentially  relay  data  from  one  to  another, 
each  station  typically  receiving,  scanning,  and  regenerating  signals  on  the 
ring.  Reliability  thus  becomes  a  factor,  since  the  failure  of  a  single 
station  may  disrupt  operation  of  the  network.  Multiple  connections  between 
stations  may  be  used  to  provide  a  measure  of  redundancy,  protecting  against 
a  limited  number  of  station  failures.  Alternatively,  fail-safe  bypassing 
of  faulty  stations  may  be  used  to  enhance  reliability. 

A  ring  topology  also  lends  itself  well  to  fully  synchronous  operation.  At 
data  rates  below  1  Mbps,  the  asynchronous  burst  mode  of  operation  supported 
by  a  bus  topology  provides  reliable  performance.  At  data  rates  above  10 
Mbps,  however,  establishing  the  synchronization  necessary  for  acceptable 
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probabilities  of  error  on  such  a  system  becomes  technically  difficult.  A 
synchronous,  phase-locked  ring  system,  on  the  other  hand,  readily  achieves 
desired  performance  levels. 

Hybrid  Topologies 

Local  area  networks  have  also  been  designed  using  mixes  of  the  above 
topologies.  For  example,  a  star-shaped  ring  is  possible  in  which  the 
stations  are  arranged  in  a  star  configuration,  connected  by  forward  and 
return  circuits  to  a  central  (passive  or  active)  node.  As  another  example, 
one  of  the  Ungermann-Bass  Net/One  LAN  configurations  defines  a  network  in 
which  a  tree  topology  interconnects  multiplexers  each  of  which  supports  a 
star  of  RS-232  cable  connections  to  the  attached  terminals.  Another 
Net/One  configuration  links  coaxial  cable  buses  via  fiber-optic  cable  into 
a  star  network. 
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4.3  LOCAL  AREA  NETWORK  MEDIA 

Many  different  types  of  transmission  media  may  be  used  In  local  area 
networks;  indeed,  a  single  network  may  utilize  a  variety  of  media.  The 
transmission  media  and  limited  physical  size  of  a  local  area  network  permit 
bit  error  rates  on  the  order  of  10"^.  Such  low  error  rates  are  in  fact 
assumed  in  the  operation  of  LAN  Data  Link  Layer  protocols.  Media  types 
include  twisted  pair  (shielded  and  unshielded),  baseband  coaxial  cable, 
broadband  coaxial  cable,  fiber-optic  cable,  and  even  unguided  media,  e.g., 
line-of-sight  RF  signals. 

Twisted  Pair 


Twisted  wire  pair  is  often  chosen  as  the  local  area  network  medium  in 
office  environments  where  22-  or  24-gauge  telephone  installations  are 
already  present.  Even  if  existing  wires  are  not  used,  its  low  cost  and 
ease  of  installation  make  twisted  wire  pair  an  attractive  choice.  High 
attenuation  limits  the  bandwidth  which  it  may  support  to  data  rates  less 
than  9.6  kbps,  however,  and,  if  not  shielded,  twisted  pair  is  prone  to 
interference  (crosstalk,  noise,  etc.). 

Coaxial  Cable 

Coaxial  cable,  on  the  other  hand,  resists  interference  and  supports  a  high 
bandwidth.  Baseband  coax  may  support  up  to  50  Mbps;  broadband  coax,  by 
using  Community  Antenna  Television  (CATV)  technology  to  provide  multiple 
frequency  division-multiplexed  channels,  may  support  up  to  150-200  Mbps. 
Broadband  cable  networks  are  either  single  or  dual  cable  systems  supporting 
separate  transmit  and  receive  channels.  In  a  dual  cable  system,  one  cable 
(or  one  segment  of  cable)  defines  the  transmit  channel  while  the  other 
cable  (or  segment)  defines  the  receive  channel;  in  a  single  cable  system, 
the  usable  bandwidth  is  split  into  transmit  and  receive  channels. 
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Broadband  cable  systems  define  a  rooted  tree  topology,  the  root  of  the  tree 
commonly  termed  the  head  end.  In  a  single  cable  network,  the  head  end 
includes  a  frequency  shifter  to  re-broadcast  in  the  receive  frequency  band 
the  signals  received  on  the  transmit  band.  Frequency  shifters  are  also 
found  in  some  dual  cable  systems  in  order  to  reduce  the  problem  of 
crosstalk  in  the  station  modems.  Alternatively,  a  dual  cable  system  may 
have  a  completely  passive  head  end  simply  by  bending  the  transmit  cable  and 
routing  it  again  to  the  attached  stations  as  the  receive  cable. 

Costs  of  a  broadband  coaxial  cable  system  are  typically  higher  than  that  of 
an  equivalent  baseband  system  as  a  result  of  the  filters  and  RF  modems  that 
are  required.  The  extended  bandwidth,  however,  allows  high  data  rates  and 
permits  the  use  of  frequency  division  multiplexing  as  a  means  of  sharing 
channel  capacity  among  the  network  stations. 

Fiber-Optic  Cable 

As  a  transmission  medium,  fiber-optic  cable  affords  numerous  advantages. 
Since  it  is  an  all-dielectric  medium,  it  exhibits  RFI  and  EMI  immunity, 
allowing  installation  in  high-voltage  environments  as  may  be  present  in 
possible  industrial  applications.  Conversely,  fiber-optic  cable  provides  a 
secure  transmission  medium  with  little  or  no  leakage  of  signal  radiation. 
The  cable's  small  size,  low  attenuation,  and  high  bandwidth  (capable  of 
supporting  rates  even  above  1  Gbps,  although  typically  on  the  order  of 
several  hundred  Mbps)  allow  more  efficient  use  of  available  conduit  or  duct 
space. 

Due  to  the  characteristics  of  laser  sources  and  the  consequent 
non-linearity  in  the  transformation  from  electric  to  optical  signals,  less 
efficient  modulation  schemes  must  be  used  in  a  fiber  optic  system  than  in  a 
coaxial  system.  Several  times  more  bandwidth  on  a  fiber-optic  cable  are 
thus  required  to  transmit  the  same  number  of  channels  as  on  a  coaxial 
system.  The  large  bandwidth  capacity  of  fiber  optics,  however,  still 
allows  many  more  equivalent  channels  than  may  be  supported  on  coaxial 
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cable.  Typical  multiplexing  techniques  for  use  with  fiber-optic  cabling 
are:  1)  time-division  multiplexing  (TDM)  combined  with  Pulse  Code 
Modulation  (PCM)  signalling;  2)  frequency-division  multiplexing  (FDM)  using 
analog  frequency  modulation  (FM);  and  3)  wavelength-division  multiplexing 
(WDM)  of  baseband  amplitude  modulated  (AM)  optical  signals. 

Interfaces  to  optical  fiber  transmission  media  are  through  either  active  or 
passive  devices.  Active  couplers  receive  all  of  the  optic  fiber's  optical 
signal  energy  and,  since  true  optical-to-optical  repeaters  are  not  yet 
available,  perform  opto-electrical  conversion,  signal  regeneration  and 
insertion,  and  then  electro-optical  conversion  for  retransmission  on  the 
medium;  passive  interfaces  provide  optical-to-optical  coupling,  receiving  a 
fraction  of  the  fiber's  optical  energy  and/or  injecting  optical  energy 
directly  into  the  cable.  Interface  costs,  electronic  complexity,  and 
reliability  concerns  are  drawbacks  to  use  of  active  devices;  the  power 
losses  and  distortions  associated  with  optical-to-optical  passive  coupling 
impose  limits  to  the  number  of  network  interfaces  if  network  power  budgets 
are  to  be  satisfied. 

Indeed,  use  of  fiber-optic  cable  in  passive  bus  or  ring  configurations  is 
not  practical  since  current  coupler  technology  severely  limits  the  number 
that  may  be  employed  in  sequence,  often  to  less  than  twenty  in  typical  such 
systems.  Manufacturers  have  instead  implemented  fiber-optic  versions  of 
bus  or  ring  networks  by  employing  active  devices  and/or  effectively 
collapsing  the  "bus"  or  "ring"  to  a  single  point,  creating  a  star 
topology.  Hybrid  interfaces  are  sometimes  used  to  provide  a  fail-safe 
coupling;  if  the  active  regenerating  unit  fails,  the  passive  coupling 
remains  intact. 

Unbounded  Media 


The  use  of  unbounded  media  in  local  area  networks  avoids  the  need  of  cable 
installation  and  provides  flexibility  in  the  location  of  network 
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stations.  Two  approaches  have  been  used  to  implement  such  wireless  indoor 
communications:  use  of  infrared  radiation  or  use  of  spread-  spectrum 
microwave  technology. 

In  indoor  applications,  infrared  radiation  (IR)  does  not  interfere  with 
existing  RF  systems  and,  since  it  is  essentially  restricted  to  the  room  in 
which  it  is  generated,  cannot  be  detected  outside  that  room  and  will  not 
interfere  with  nearby  systems  in  different  rooms.  Data  transmission  rates 
as  supported  by  IR  systems  are  limited  by  the  effects  of  multipath,  ambient 
light,  and  the  transient  times  of  the  employed  light-emitting  diodes 
(LED's).  Assuming  ambient  light  to  be  restricted  in  the  facility,  data 
rates  are  effectively  limited  by  the  LED  rise  and  fall  times;  for  the 
Siemens  LD-271  or  Gilway-E14  LED's,  for  example,  this  limitation  is  on  the 
order  of  500  kbps.  In  experimental  IR  systems,  however,  lower  data  rates 
have  typically  been  achieved.  Due  to  the  multipath  environment  which  IR 
communications  are  subjected,  digital  coiranuni cat ions  are  best  effected  if 
carrier  synchroni2ation  is  avoided,  suggesting  use  of  non-coherent 
communications  techniques  such  as  non-coherent  FSK  or  differentially 
coherent  phase  shift  keying  (PSK). 

To  counteract  the  effects  of  multipath  and  frequency  selective  fading  in 
closed  environments,  spread-spectrum  RF  or  IR  signals  may  be  used, 
additionally  reducing  the  possibilities  of  interference  and  detectability. 
Furthermore,  shared  utilization  of  a  given  channel  bandwidth  may  be 
accomplished  through  code-division  multiple-access  (CDMA).  In  a 
decentralized  system,  however,  use  of  spread-spectrum  techniques  involves 
considerable  expense. 

Unbounded  media  have  not,  however,  been  popular  choices  for  the  designers 
of  local  area  networks.  Spatial  limitations,  security  worries,  and  cheaper 
and  more  available  alternatives  have  restricted  the  usage  of  unbounded 
media. 
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4.4  LOCAL  AREA  NETWORK  ACCESS  CONTROL  TECHNIQUES 

While  the  network  topology  defines  the  connectivity  of  the  network,  the 
flow  of  communications  among  stations  is  regulated  by  the  network's 
employed  access  control  protocol.  The  development  of  local  area  networks 
has  been  spurred  by  the  need  to  support  computer  communications.  To 
efficiently  accommodate  the  bursty  generation  of  traffic  typical  of  such 
communications,  local  area  networks  generally  provide  packet-  or  message- 
switched  services  over  a  shared  communications  resource.  Three  basic 
channel  access  strategies  are  possibleas  shown  in  Figure  4-3:  reservation, 
selection,  and  random  access.  And,  depending  on  the  details  of  the 
particular  access  control  technique,  implementation  of  the  control  strategy 
is  either  through  centralized  control  of  network  communications  or  by  use 
of  distributed,  decentralized  control. 

Centralized  Versus  Distributed  Access  Control 
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Centralized  control  of  a  local  area  network  implies  the  presence  of  a 
network  controller  coordinating  network  communications;  in  a  decentralized 
network,  the  intelligence  to  coordinate  network  communications  is  provided 
by  each  of  the  attached  stations. 


In  a  centralized  network,  the  central  controller  administers  the  flow  of 
communications  on  the  network.  Typically,  an  individual  station's 
responsibility  is  to  respond  to  a  network  condition  or  an  explicit  query 
and  at  that  time  gain  access  to  the  channel;  coordination  of  these 
activities  is  the  role  of  the  central  controller.  The  failure  of  the 
central  controller  generally  implies  failure  of  the  network.  Often, 
however,  centralized  control  is  employed  in  networks  where  the  attached 
stations  are  subordinate  to  a  central  processor  which,  additionally,  serves 
as  network  controller.  In  such  systems,  continued  functioning  of  the 
network  in  the  event  of  failure  of  the  central  processor  is  probably  of  no 
use  anyway. 
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Either  form  of  network  control,  centralized  or  distributed,  may  generally 
be  employed  in  an  arbitrary  network,  but  distributed  control  perhaps  most 
suits  those  networks  composed  of  autonomous  devices  engaged  in  peer-to- 
peer  communications.  In  such  cases,  the  processing  power  needed  to 
administer  network  control  is  presumably  readily  available.  On  the  other 
hand,  if  an  attached  device  does  not  possess  the  needed  processing 
capabilities,  then  the  required  network  intelligence  must  be  provided  by 
that  station's  interface  unit.  By  distributing  access  control 
responsibilities  in  this  manner,  network  reliability  is  typically  enhanced. 

Reservation  Access  Control  Techniques 

In  reservation  techniques  of  channel  access  control,  a  station  transmits  a 
data  packet  according  to  a  predetermined  allocation  of  channel  capacity. 
Once  channel  capacity  is  reserved  for  a  particular  station,  no  further 
external  coordination  or  control  is  needed  to  permit  that  station  to  access 
the  shared  channel.  Channel  capacity  is  typically  shared  through  time 
division  multiple  access  (TOMA):  capacity  is  allocated  by  granting  a 
station  an  individual  slot  of  time  long  enough  for  the  transmission  of  one 
message/packet.  Frequency  division  multiple  access  (FOMA)  and  code 
division  multiple  access  schemes  may  also  be  seen  as  reservation 
techniques,  but  neither  scheme  is  often  used  in  local  area  networks  since 
the  resultant  circuit-switched  capability  is  generally  inappropriate  for 
bursty  computer  communications. 

Channel  capacity  may  be  reserved  in  a  static  or  dynamic  fashion.  Static 
assignments  of  capacity  may  lead  to  under-utilization  of  the  channel,  hence 
the  desirability  of  a  dynamic  reservation  scheme.  Centralized  control  is 
typically  used  in  TOMA  reservation  access  techniques  in  order  to  establish 
synchronization  among  the  stations  of  the  network.  In  typical  dynamic 
reservation  schemes,  a  centralized  controller  dynamically  allocates  channel 
capacity  on  the  basis  of  station  requests  for  access.  Asynchronous  time 
division  multiple  access,  also  known  as  statistical  multiplexing,  is  an 
example  of  such  a  dynamic  reservation  technique.  Distributed  control 
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dynamic  reservation  techniques  are  also  possible,  although  these  have 
generally  been  proposed  for  the  access  control  of  satellite  channels  rather 
than  for  local  area  networks. 

Selection  Access  Control  Techniques 

Selection  protocols,  rather  than  reserving  capacity,  effectively  choose 
which  users  may  access  the  channel  at  a  given  time.  A  station  may  only 
access  the  channel  when  it  has  been  appropriately  signalled  ("selected"); 
before  selection,  the  station  must  buffer  all  data  to  be  transmitted  until 
access  is  granted.  Selection  techniques  may  be  implemented  using  either 
centralized  or  distributed  control. 

With  centralized  control,  the  signals  prompting  a  station  to  transmit  on 
the  shared  channel  are  generated  by  a  central  channel  controller.  In  roll- 
call  polling  systems,  for  example,  the  central  controller  addresses  the 
network  stations  one  at  a  time;  stations  with  message  packets  to  transmit 
do  so  only  upon  being  polled.  The  sequence  in  which  stations  are  polled 
may  be  either  fixed  or  variable;  indeed,  priorities  among  stations  may  be 
established  by  polling  particular  stations  multiple  times  within  a  single 
polling  cycle.  Other  versions  of  centralized  selection  access  control 
involve  use  of  a  control  channel  to  either  signal  stations  that  they  may 
access  the  shared  channel  ("daisy  chaining")  and/or  allow  stations  to 
independently  request  channel  access  from  the  central  controller. 

Decentralized  selection  access  techniques  are  also  possible,  one  such 
technique,  token  passing,  being  among  the  standards  proposed  by  the  IEEE 
802  committee.  In  token  passing  systems,  access  control  is  regulated 
through  possession  of  the  "token,"  a  token  typically  being  control  bits 
within  a  data  frame.  If  the  station  with  the  token  has  data  to  transmit, 
it  sends  its  data  and  then  passes  the  token  to  the  next  station.  If  the 
station  has  no  data  to  transmit,  it  passes  the  token  immediately.  Stations 
receive  the  token  in  sequence,  thereby  establishing  a  maximum  time  which  a 
station  must  wait  in  order  to  access  the  channel.  The  sequential  granting 
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of  access  characteristic  of  token  passing  makes  this  technique  very 
appropriate  for  sequential  media  and  ring  topologies,  resulting  in  the 
"token  ring."  The  sequential  passing  of  control  may  also  be  constructed 
logically  on  broadcast  media,  hence  the  "token  bus."  Furthermore,  priority 
schemes  may  be  implemented  by  only  allowing  those  stations  with  the  highest 
priority  to  access  the  channel  every  time  the  token  is  received. 

Random  Access  Control  Techniques 

Random  access  control  techniques  attempt  to  provide  channel  access  to 
stations  upon  demand.  A  station  must  either  wait  to  be  granted  access  in  a 
selection  system  or  must  wait  for  its  pre-arranged  access  in  a  reservation 
system — in  a  random  access  system,  a  station  may  ideally  access  the 
channel  at  any  time.  By  definition,  then,  control  of  a  random  access 
system  is  distributed.  Uncontrolled  or  controlled  random  access  techniques 
are  possible,  although  the  archetypical  uncontrolled  random  access 
technique,  pure  ALOHA,  is  known  more  for  historic  and  academic  than 
practical  significance.  In  controlled  random  access  systems,  stations  are 
not  "deaf"  but  possess  some  knowledge  of  channel  activity. 

The  best  known  example  of  a  random  access  control  protocol  is  Carrier  Sense 
Multiple  Access  with  Collision  Detection  (CSMA/CD).  Implemented  by 
DEC/Intei/Xerox  as  "Ethernet",  the  CSMA/CD  algorithm  has  been  standardized 
by  the  IEEE  802  committee. 

The  CSMA/CD  technique  defined  by  DEC/Intel/Xerox  and  the  802  committee  is 
but  one  variation  of  the  many  possible  carrier  sense  multiple  access 
techniques  in  which  stations  monitor  activity  on  a  shared  broadcast  channel 
and  attempt  transmission  when  the  channel  is  sensed  idle.  The  CSMA/CD 
algorithm  of  Ethernet  and  the  802  committee  is  known  in  the  research 
literature  as  1-persistent  CSMA/CD.  In  this  algorithm,  stations  with  a 
data  packet  (frame)  ready  to  transmit  sense  the  channel  before  beginning 
their  transmission.  If  the  channel  is  sensed  idle,  transmission  begins;  if 
sensed  busy,  transmission  is  deferred  until  the  channel  is  again  sensed 
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idle.  At  that  time,  transmission  is  again  attempted  after  a  fixed  duration 
interframe  gap  used  to  allow  the  transceivers  and  channel  to  stabilize 
between  transmissions.  Transmission  is  attempted  regardless  of  whether  the 
channel  is  sensed  idle  or  busy.  It  is  this  behavior  upon  deferring 
transmission  which  is  termed  1-persistent:  after  deferring  its 
transmission,  a  station  persists  in  its  attempt,  trying  again  with 
probability  one.  Contrast  this  response  to  that  of  p-persi stent  CSMA, 
which  transmits  after  deferral  with  probability  p.  In  non-persistent  CSMA, 
on  the  other  hand,  a  station  treats  a  deferral  as  if  a  collision  had 
occurred. 

Due  to  propagation  delays  on  the  shared  channel,  two  or  more  stations  may 
sense  the  channel  idle  and  attempt  concurrent  transmissions,  resulting  in  a 
collision  on  the  broadcast  channel.  Such  collisions  are  detected  by  the 
colliding  stations  who  then  continue  their  transmission  for  a  fixed  number 
of  bits,  jamming  the  channel  to  insure  that  all  stations  sense  the  channel 
as  busy.  Retransmission  is  scheduled  according  to  the  value  determined  by 
"truncated  binary  exponential  backoff:"  a  delay  of  r  slot  times  is 
observed— one  slot  equaling  a  fixed  number  of  bit-times — before  the  n-th 
retransmission  attempts.  The  value  of  r  is  chosen  as  a  uniformly 
distributed  random  integer  in  the  range  of  0  <  r  <  2k,  where  k  is  either 
the  number  of  retransmission  attempts,  n,  or  some  predetermined  backoff 
limit,  whichever  is  smaller.  Some  degree  of  prioritization  among  stations 
is  possible  by  different  assignments  of  scheduling  delays,  but  this 
technique  is  not  specifically  part  of  the  802  committee  specifications. 
Transmission  is  attempted  a  limited  total  number  of  times;  if  all  allowed 
attempts  fail,  the  attempt  is  abandoned  and  an  error  is  reported  to  higher 
protocol  layers. 

The  parameter  of  slot  time  mentioned  above  is  not  just  arbitrarily 
selected.  The  slot  time,  the  unit  of  time  used  in  scheduling 
retransmissions,  must  be  an  upper  bound  on  the  acquisition  time  of  the 
medium  and  on  the  length  of  the  frame  fragment  generated  by  a  collision. 
Clearly,  the  slot  time  is  determined  by  the  netwo^ x  implementation:  it 
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must  be  larger  than  the  sum  of  the  maximum  network  round-trip  propagation 
time  and  jam  time.  The  parameter  values  specified  by  the  802  committee  and 
DEC/Intel/Xerox — the  minimum  and  maximum  frame  sizes,  the  jam  size,  the 
maximum  network  configuration,  the  backoff  limit,  transmission  media 
characteristics,  transmission  rate,  interframe  gap  size,  etc. — effectively 
fine-tune  the  CSMA/CD  algorithm  to  realize  optimal  performance. 

The  CSMA/CD  algorithm,  of  course,  is  a  random  access  technique  and  so 
exhibits  probabilistic  delay  performance.  In  certain  applications  such 
local  area  network  behavior  may  not  be  acceptable,  requiring  instead  use  of 
a  selection  or  reservation  technique.  On  the  other  hand,  adaptive  access 
control  techniques  have  been  researched  which  exhibit  the  qualities  of 
random  access  schemes  at  low  traffic  levels  and,  in  the  presence  of  higher 
loads,  of  reservation  or  selection  access  techniques.  While  such 
techniques  are  not  presently  under  consideration  by  the  802  committee,  they 
do  hold  promise  for  future  networks. 
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4.5  LAN  ACCESS  PROTOCOL  PERFORMANCE  CRITERIA 

Local  area  networks  are  employed  to  satisfy  specific  communications  needs; 
their  performance  must  therefore  be  assessed  with  regard  to  the  fulfillment 
of  those  needs.  The  distinctive  characteristic  of  a  local  area  network, 
however,  is  the  shared  utilization  of  a  common  channel.  Comparison  of 
local  area  networks,  then,  is  often  based  on  the  relative  performance 
capabilities  of  the  employed  access  control  technique. 

Performance  of  an  access  protocol  depends  on  the  density  of  traffic  that  is 
supported.  To  quantify  the  demands  made  on  the  communications  capability 
of  a  local  area  network,  one  speaks  of  the  traffic  intensity  or  load.  Load 
is  defined  as  the  sum  over  all  of  the  network  stations  of  the  product  of 
the  mean  arrival  rate  (in  frames  per  second)  and  the  mean  frame  size  (in 
seconds)  for  each  individual  station.  Note  that  the  definition  of  load 
implicitly  considers  the  network  transmission  rate.  On  a  shared  channel,  a 
load  of  unity  represents  a  demand  for  the  full  network  capacity;  loads 
greater  than  unity  may,  of  course,  be  presented  to  the  network  by  the 
connected  stations,  but  a  shared  channel  cannot  physically  provide  such 
service  without  degraded  network  performance.  In  star  networks  and  some 
ring  systems,  however,  traffic  may  flow  independently  between  neighboring 
stations,  allowing  network  loads  greater  than  unity  to  be  fully 
supported.  Measurements  of  operational  local  area  networks  indicate  that 
average  traffic  loads  are  typically  much  less  than  maximum,  but 
instantaneous  loads  may  reach  high  levels.  As  a  function  of  load,  then, 
the  following  indicators  provide  a  measure  of  access  control  performance: 
throughput,  delay,  queue  size,  rejection  rate,  and  failure  rate.  Of  these 
performance  indicators,  throughput  and  delay  are  the  most  important. 

Throughput 

Throughput,  as  opposed  to  data  rate  or  transmission  rate,  refers  to  the 
fraction  of  time  which  the  system  is  successfully  being  utilized.  A 
distinction  is  sometimes  made  between  network  throughput  and  data 
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LAN  ACCESS  PROTOCOL  PERFORMANCE  CRITERIA 


•  LOAD:  TRAFFIC  INTENSITY  TO  BE  SUPPORTED  BY  NETWORK 

•  THROUGHPUT:  FRACTION  OF  TIME  THE  NETIWRK  IS  SUCCESSFULLY  UTILIZED 

-  NETWORK  THROUGHPUT 

-  DATA  THROUGHPUT 

DELAY:  INTERVAL  BETWEEN  TRANSMISSION  REQUEST  AND  SUCCESSFUL  TRANSMISSION 

-  SELECTION  AND  RESERVATION  PROTOCOLS 
~  INVOLVE  DELAY  OVERHEADS  AT  ALL  LOAD  LEVELS 
—  PROVIDE  LIMITED  PACKET  DELAYS  UNDER  HEAVIEST  LOADING 

-  RANDOM  ACCESS  PROTOCOLS 
—  PACKET  DELAYS  INCREASE  WITH  TRAFFIC  INTENSITY 
—  REDUCED  DELAY  OVERHEAD  FOR  LIGHT  LOADS 


QUEUE  SIZE 

REJECTION  RATE 

FAILURE  RATE:  RANDOM  ACCESS  PROTOCOLS  ONLY 
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throughput.  Network  throughput  considers  the  fraction  of  time  which  the 
system  is  successfully  transmitting  data,  including  all  overhead 
information;  data  throughput,  on  the  other  hand,  does  not  include  the  time 
spent  in  transmitting  overhead  information  and  thus  reflects  only  that 
fraction  of  the  channel  capacity  used  to  transmit  the  ultimately  desired 
data.  Overhead  in  the  sense  used  here  refers  to  those  portions  of  each 
data  frame  required  by  the  various  protocol  layers  for  their  proper 
operation.  Such  overhead  may  be  in  the  form  of  data  preambles  for 
synchronization  purposes,  source  and  destination  addresses,  cyclic 
redundancy  check  codes  used  for  error-checking,  frame  delimiters,  etc.  or 
may  be  manifest  as  additional  channel  traffic  generated  as  part  of  normal 
network  operation  (data  frames,  for  example,  acknowledging  a  correctly 
received  packet).  To  avoid  consideration  of  all  the  possible  aspects  of 
data  overhead,  most  discussions  of  LAN  performance  consider  only  network 
throughput. 

Network  throughput  is  very  much  a  function  of  the  access  control  protocol 
employed  by  the  local  area  network.  For  example,  computer  simulation  of  a 
local  area  network  using  CSMA/CD  as  specified  by  the  IEEE  802  committee 
reveals  that  network  throughput  typically  equals  the  load  up  a  level  of 
approximately  .5.  At  loads  greater  than  .5,  network  throughput  scmewhat 
lags  behind  the  increased  demand  of  network  resources  as  a  consequence  of 
collisions  and  the  contention  resolution  process,  reaching  a  maximum  level 
of  approximately  .95.  Such  performance  represents  almost  complete 
utilization  of  the  channel  capacity,  but  other  network  performance  suffers. 

Delay 

Besides  throughput,  the  most  important  indicator  of  a  network's  performance 
is  the  delay  a  frame  incurs  from  the  time  transmission  is  requested  until 
successful  transmission  is  finally  accomplished.  At  high  load  levels, 
individual  data  packets  suffer  relatively  greater  delays  in  return  for  high 
system  throughput.  Excessive  delays  may  limit  the  utility  of  the  network 
and  impede  operation  of  individual  users.  The  transmission  of  digitized 
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voice  packets,  for  example,  cannot  be  successfully  supported  when  lengthy 
delays  prohibit  real-time  re-assembly  of  the  packets. 

Delays  may  be  intrinsic  to  the  operation  of  the  access  control  technique; 
for  example,  when  a  station  must  wait  to  be  selected  or  must  wait  for  its 
reserved  channel  slot  before  transmitting.  Such  delay  overhead  is  a  major 
aspect  of  selection  and  reservation  techniques,  although  the  overhead  may 
be  insignificant  for  performance  at  high  traffic  levels.  At  low  traffic 
levels,  however,  the  delay  overhead  involved  in  reservation  or  selection 
multiaccess  protocols  typically  exceeds  that  incurred  by  random  access 
protocols.  Figure  4-4  provides  a  representative  example  of  the  delay- 
throughput  tradeoff  involved  in  selection,  reservation,  and  random  access 
schemes.  The  implementation  of  a  system  may  also  incur  delay.  For 
example,  data  packets  awaiting  transmission  at  each  station  are  typically 
buffered.  Intuitively,  one  expects  a  frame's  mean  waiting  time  to  be 
sensitive  to  the  buffer  size  of  each  station:  as  longer  queues  are  allowed 
by  a  greater  buffer  capacity,  the  waiting  times  in  those  queues  should 
consequently  increase. 

Queue  Size,  Rejection  Rate,  and  Failure  Rate 

Other  performance  indicators  besides  throughput  and  delay  are  significant, 
although  not  often  considered  in  the  assessment  of  access  control  technique 
performance. 

Queue  size,  as  mentioned  above,  refers  to  the  buffering  of  data  frames 
ready  for  transmission.  Queue  size  at  any  one  station  reflects  both 
network  performance  (i.e.,  how  efficiently  media  access  is  granted)  and  the 
particular  frame  generation  rate  at  that  station.  For  example,  the  queue 
size  of  two  different  stations  with  the  same  message  generation  rate  on  two 
different  but  comparable  networks  will  most  likely  be  approximately 
identical  until  fairly  high  arrival  rates  are  reached.  At  that  point,  if 
the  network  load  levels  are  different,  the  network  performance  in  servicing 
frames  in  each  station's  buffer — a  function  of  load,  not  frame  generation 
rate — begins  to  be  the  major  factor  affecting  queue  size. 
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The  most  serious  impact  of  a  station's  buffer  size  is  demonstrated  by  the 
rejection  rate,  the  rate  at  which  frames  are  turned  away  from  full  station 
buffers.  A  non-zero  rejection  rate  represents  the  failure  of  the  access 
protocol  and  the  station  buffers  to  accoumiodate  the  offered  load.  Like 
queue  size,  the  rejection  rate  can  be  expected  to  depend  not  just  on  system 
load,  but  also  on  the  arrival  rate  of  frames  to  each  station. 

The  failure  rate  refers  to  the  rate  at  which  data  frames  fail  to  gain 
access  to  the  channel  in  the  required  number  of  attempts.  In  terms  of  the 
OSI  Reference  Model,  the  failure  is  on  the  part  of  the  data  link  layer  and 
must  be  reported  to  higher  protocol  layers  for  appropriate  action.  Such 
media  access  failure  is  generally  only  possible  for  random  access  control 
techniques;  in  reservation  or  selection  systems  the  delivery  of  a  data 
frame  is  ultimately  guaranteed,  barring  other  types  of  failure.  This 
behavior  thus  defines  the  trade-offs  typically  involved  in  using  a  random 
access  technique;  in  return  for  reduced  waiting  times  at  low  load  levels, 
performance  at  high  loads  may  be  subject  to  such  failures  to  achieve 
channel  access. 
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SECTION  5 

APPLICATION  OF  LAN  TECHNOLOGY  TO  DSCS  SUBSYSTEM  INTEGRATION 


5.1  INTRODUCTION 

The  interconnection  of  OSCS  terminal  devices  involves  the  support  of  two 

types  of  intercommunications:  the  communication  flows  between  devices  in 
support  of  OSCS  user  communications  and  the  flow  of  equipment  control  and 
status  signals  within  the  terminal. 

The  concepts  presented  here  reflect  four  specific  LAN  design  goals: 

•  functionality; 

•  flexibility; 

•  reliability;  and, 

•  moderate  cost. 

Any  proposed  LAN  design  must  fully  address  the  system  communication 
needs.  Moreover,  in  fulfilling  those  needs  the  design  should  exhibit  a 
high  degree  of  modularity  to  foster  efficient  production,  installation,  and 
maintenance.  Complexity  is  to  be  avoide'd  in  ordef  * to  guarantee  the 
reliability  of  the  local  area  network — the  functioning  of  the  DSCS 
terminal  must  not  be  compromised  by  failure  of  the  terminal's  local  area 
network.  Future  growth  of  ary  DSCS  terminal  facility  must  not  be 
restricted  by  the  local  area  network  design — the  LAN  must  allow  for 
expansion.  And,  finally,  the  development  and  production  costs  of  the  local 
area  network  should  not  be  excessive.  The  application  of  local  area 
network  technology  to  satisfy  these  goals  in  DSCS  earth  terminals  leads  to 
two  distinct  design  approaches. 
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The  first  approach  addresses  both  types  of  DSCS  terminal 
intercommunications.  A  full  intercommwni cations  LAN  is  envisioned  which 
will  support  both  the  control  and  status  signal  flows  and  also  the 
dedicated  DSCS  user  channels  within  an  earth  terminal.  The  high  aggregate 
data  rates  and  the  need  for  dedicated  reliable  service  lead  to  a  fairly 
specific  design  concept. 

If  the  interconnection  of  terminal  devices  needed  to  support  the  DSCS 
satellite  circuits  is  accomplished  through  some  other  means  (e.g.,  by 
manual  patching  as  is  currently  employed  or,  perhaps,  by  some  application 
of  digital  switching  technology  as  suggested  in  Section  6  of  this  report), 
then  a  local  area  network  may  be  used  to  handle  only  the  data  traffic 
generated  by  control  and  status  monitoring  functions.  Such  a  control  and 
status  LAN  may  be  implemented  in  a  variety  of  ways,  as  will  be  discussed. 
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5.2  FULL  INTERCOMMUNICATIONS  LAN 

Introduction 

A  full  terminal  intercommunications  LAN  must  provide  three  distinct 
capabi ■ ities: 

•  the  local  area  network  must  support  the  signal  interconnection  of 
the  various  terminal  components  and  subsystems; 

•  the  local  area  network  must  provide  a  means  of  configuration 
control,  allowing  interconnections  to  be  made  and  broken  upon 
command;  and, 

•  the  local  area  network  must  provide  for  the  communication  of 
equipment  control  and  status  signals. 

To  support  full  terminal  intercommunications  and  maintain  transparency  to 
DSCS  users,  a  local  area  network  capable  of  providing  circuit-switched 
communications  is  necessary — packetization  of  user  communications  solely 
for  intra-terminal  communications  would  introduce  unwanted  complexity. 
Furthermore,  while  DSCS  terminals  support  aggregate  user  data  rates  ranging 
from,  say,  5  to  30  Mbps,  as  discussed  in  Section  3,  the  local  area  network 
must  provide  a  dedicated  channel  between  each  equipment  pair  in  the 
equipment  chains  supporting  the  user  communications  signals.  As  a 
consequence,  the  capacity  of  a  terminal's  full  intercommunication  LAN  must 
be  some  factor  greater  than  the  supported  aggregate  user  data  rate.  Since 
the  earth  terminal  throughputs  discussed  in  Section  3  presume  full  deplex 
communications,  a  full  intercommunications  LAN  must  support  at  least  twice 
the  indicated  aggregate  user  data  rates.  The  above  functional  requirements 
alone  lead  to  the  elimination  of  many  of  the  possible  local  area  network 
options,  as  indicated  in  Table  5-1:  the  need  to  provide  dedicated  channels 
disallows  the  use  of  selection  or  random  access  protocols;  the  required 
capacity  eliminates  all  but  fiber-optic  or  broadband  coaxial  cable  or 
unbounded  media  from  consideration. 
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FULL  IWTERC0>»IUN1CATI0NS  LAN:  INTRODUCTION 


SUPPORTS  INTERCONNECTION  OF  DEVICES  FOR  RELAY  OF  USER  COIMJNICATIONS 
THROUGH  OSCS  EARTH  TERMINAL 


SUPPORTS  INTERCQtMJNICATION  OF  CONTROL  AND  STATUS  SIGNALS  BETWEEN  DSCS 
TERMINAL  EQUIPMENT  AND  CONTROL/STATUS  MONITOR  PROCESSOR(S) 
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The  DSCS  full  intercommunications  LAN  conceived  here,  then,  must  be  a 
broadband  network  with  access  controlled  by  a  reservation  scheme.  Of  all 
the  possible  topologies,  a  bus  is  the  most  appropriate,  providing  a 
reliable  local  area  network  without  implicitly  favoring  any  of  the  attached 
stations.  Other  topologies  could  be  successfully  implemented,  of  course, 
but  none  reliably  suits  the  DSCS  terminal  connectivities  and  need  for 
dedicated  channels  as  well  as  a  bus. 

Of  the  three  possible  media  choices,  broadband  coaxial  cable  is  the  most 
mature  technology  and  hence  the  most  conservative  alternative;  as  such,  it 
may  be  an  appropriate  choice  for  OSCS  applications.  The  support  of  a  local 
area  network  by  radio  frequency  transmission  poses  RFI  and  security 
concerns,  while  the  use  of  IR  transceivers  raises  issues  surrounding  the 
development  costs  of  high  data  rate  devices  and  the  need  for  special  care 
in  their  installation.  Optical  fiber  could  certainly  provide  the  needed 
bandwidth  for  a  full  intercommunications  LAN,  but  current  technology  does 
not  provide  reliability  and  performance  on  the  level  of  broadband  coaxial 
cable.  Fiber-optic  cable  used  in  a  bus  topology  using  passive  devices,  for 
example,  imposes  limits  to  the  number  of  connections  and  the  extent  of  the 
local  area  network  as  a  result  of  the  insertion  losses  imposed  by  each 
attached  device;  use  of  active  devices  in  a  bus  configuration  is  possible, 
but  reliability  of  the  LAN  then  becomes  a  concern  unless  a  fail-safe  design 
is  employed.  Finally,  current  technology  limits  the  dynamic  range  of 
optical  receivers  to  approximately  25  dB  over  250  MHz;  such  performance  may 
be  inadequate  for  the  purposes  of  the  full  intercommunication  LAN  which 
must  handle  analog  as  well  as  digital  signals. 

To  elucidate  issues  concerning  the  use  and  development  of  a  full 
intercommunications  LAN  appropriate  to  OSCS  terminals,  a  specific  example 
of  a  design  is  considered  in  the  following  subsections.  A  broadband 
coaxial  bus  using  frequency  division  multiple  access  (FOMA)  and  similar  to 
the  Shipboard  Communications  Area  Network  (SCAN)  developed  by  the 
Department  of  the  Navy  is  described.  Other  reservation  access  control 
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schemes  besides  FOMA  might  also  be  used,  but  for  illustrative  purposes  FDMA 
suffices  in  demonstrating  the  concepts  needed  to  support  full  terminal 
intercommunications.  Use  of  TDMA  or,  more  appropriately,  ATDMA  would  also 
be  a  possible  approach,  but  such  systems  assume  that  all  communications  are 
digital  and  are  typically  centralized,  dependent  upon  reliable  operation  of 
the  central  node  for  proper  LAN  performance — by  contrast,  the  local  area 
network  described  here,  like  SCAN,  implements  the  FDMA  access  control 
protocol  in  a  decentralized  fashion. 

Indeed,  the  SCAN  system  may  be  sufficiently  flexible  that  the  local  area 
network  detailed  here  might  take  advantage  of  equipment  developed  for 
SCAN.  SCAN  has  also  served  as  the  model  for  the  Data  Bus  of  the  Defense 
Communications  Agency's  Modular  Building-Block  concept.  In  that 
application,  however,  the  bandwidths  of  the  channels  are  not  as  wide  as 
required  to  support  the  full  earth  terminal  intercommunications  under 
discussion  here. 


Representative  Design  Concept 


The  previous  discussion  has  indicated  the  generic  capabilities  which  a  full 
intercommunications  LAN  must  provide  in  order  to  satisfy  the  communications 
requirements;  the  following  example  allows  various  design  issues  and 
considerations  to  be  explored.  As  a  representative  implementation,  then, 
the  DSCS  full  intercommunications  LAN  may  be  conceived  as  a  broadband  bus 
supported  by  coaxial  cable  and  using  frequency  division  multiplexing  to 
achieve  circuit-switching  capabilities. 


By  establishing  frequency  division  multiplexed  channels  on  the  broadband 
network,  dedicated  circuit-switched  channels,  both  digital  and  analog, 
between  terminal  equipment  may  be  maintained — separate  and  distinct 
frequency  channels  on  the  local  area  network  define  the  connectivity 
between  attached  devices.  Appendix  C  provides  estimates  of  the 
interconnections  involved  in  the  baseline  light,  medium,  and  heavy 
terminals,  classifying  the  connections  in  terms  of  the  associated  data 
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rates.  These  connections  are  full  duplex,  however,  meaning  that  2  channels 
are  required  for  every  one  indicated  in  Tables  C-1  through  C-4.  Arbitrary 
channels  are  assumed  in  those  tables  which  are  capable  of  supporting  the 
actual  data  rates.  Thus,  for  example,  the  heavy  terminal  requires 
approximately  4  channels  (2  duplex  channels)  supporting  as  much  as  8  Mbps, 

16  channels  at  2  Mbps,  6  channels  at  1  Mbps,  12  channels  at  500  kbps,  28 
channels  at  64  kbps,  and  2  channels  at  1  kbps.  These  numbers  indicate  that, 
in  order  to  support  these  interconnections,  the  LAN  must  provide  62 
dedicated  channels  (31  duplex  channels)  with  a  total  capacity  of: 

(4x8)+  (16  *  2)  +  (6  *  1)  +  (12  *  .5)  +  (28  *  .064)  +  (2  *  .001)  =  77.8  Mbps. 

Other  channels  would  be  required  to  interconnect  redundant  equipment  and  to 
connect  those  user  circuits  which  involve  no  multiplexing  but  are  routed 
directly  to  a  modem.  If  user  connections  to  the  multiplexers  are  supported 
by  the  full  intercommunications  LAN-— an  issue  discussed  in  a  succeeding 
subsection — then  the  channels  specified  in  Table  3-1  of  Section  3.5  must 
also  be  supported.  For  the  baseline  heavy  terminal,  381  duplex  user 
channels  provide  a  throughput  of  37.46  Mbps,  indicating  that  762  full 
intercommunications  LAN  channels  are  needed,  supporting  74.92  Mbps.  The 
full  intercommunications  LAN  for  a  heavy  terminal  must  thus  support  either 
-80  Mbps  or,  if  user  circuits  are  directly  linked  to  the  LAN,  a  total  of 
-155  Mbps.  Guard  bands  between  channels  will  also  be  necessary,  further 
utilizing  local  area  network  bandwidth,  but,  even  so,  these  rough 
calculations  demonstrate  that  a  broadband  coaxial  cable  LAN  can  be  used  to 
support  the  terminal  throughput.  The  actual  channel  allocations  and 
bandwidths,  of  course,  must  be  defined  more  rigorously  if  such  an  FOMA 
broadband  LAN  is  to  be  implemented. 

An  additional  channel  (or  channels)  may  be  used  to  support  the 
communications  of  local  area  network  control  signals  and  control  and  status 
data  between  DSCS  terminal  equipment  and  the  controlling/monitoring 
processor(s) .  The  bandwidth  provided  by  coaxial  cable  readily  allows 
dedicated  circuit-switched  channels  to  be  allocated  for  each  of  the  low 
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data  rate  control  and  status  signal  flows,  but  a  more  efficient  use  of 
channel  capacity  may  be  realized  if  all  control  and  status  signals  are 
transmitted  via  packet-  switching  on  the  same  channel.  Control  of  the 
local  area  network  itself — specifically,  the  allocation  and  re-  allocation 
of  channels — may  similarly  be  co-ordinated  in  a  packet-switched  manner  on 
the  equipment  control  and  status  channel  or  on  a  separate  LAN  control 
channel . 

The  envisioned  full  intercommunications  LAN  would  not  support  the 
interconnection  of  terminal  signals  at  IF:  routing  of  signals  between  the 
IF  patch  panel  and  the  terminal  RF  subsystems  would  be  accomplished  in  the 
current  manner  without  benefit  of  the  LAN.  If,  on  the  other  hand,  IF 
signals  were  to  be  relayed  by  the  local  area  network,  the  required 
complexity  of  the  network  interface  units  would  be  considerably 
increased.  The  full  intercommunications  LAN  would,  as  one  of  its 
functions,  support  the  Intercommunication  of  control  and  status  signals 
among  terminal  devices,  including  those  from  the  various  RF  subsystems  and 
equipment.  The  communication  of  all  equipment  control  and  status  signals 
via  a  local  area  network  as  suggested  here,  however,  reflects  aspects  of 
how  the  control  and  status  monitoring  functions  are  accomplished— such 
issues  are  discussed  in  Section  5.3  concerning  the  control  and  status  LAN. 

Figure  5-1  illustrates  how  terminal  devices  would  connect  through  network 
interface  units  to  the  broadband  coaxial  cable.  A  semi-rigid  cable  may  be 
used  as  the  LAN  trunk  with  connections  between  the  trunk  and  network 
interface  units  made  by  flexible  drop  coaxial  cables.  A  passive  dual  cable 
approach  using  directional  couplers  increases  reliability  by  avoiding  the 
active  frequency-  translating  head  ends  often  used  in  broadband  coaxial 
systems.  Each  piece  of  LAN-supported  equipment  connects  to  a  network 
interface  unit  which,  in  turn,  connects  to  the  transmit  and  receive  legs  of 
the  dual  cable  system. 
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In  SCAN,  reliability  is  further  enhanced  by  connecting  all  stations  to  a 
secondary  dual  cable  system  physically  separated  from  the  primary  system 
for  redundancy.  In  that  case,  each  network  interface  unit's  transceiver  is 
coupled  to  the  two  cables,  transmitting  on  both  at  all  times  and  receiving 
from  one  or  the  other  according  to  switch  selection.  Switching  between 
primary  and  secondary  cable  systems  in  the  event  of  failure  of  the  primary 
system  may  be  performed  by  central  command  on  the  basis  of  degraded 
performance  or  automatically  by  each  transceiver  on  the  basis  of  monitoring 
a  pilot  tone  on  the  primary  cable.  Such  redundancy  is  appropriate  to  SCAN 
where  the  LAN  may  be  subject  to  battle  damage,  but  may  not  be  necessary  in 
a  DSCS  earth  terminal. 

Figure  5-2  indicates,  as  an  example,  the  functional  capabilities  of  a 
broadband  bus  full  intercommunications  LAN.  The  interconnection  of 
terminal  equipment  via  channels  of  the  broadband  bus  is  illustrated, 
assuming  that  circuit  service  channels  are  provided  for  the  connections 
between  devices  and  that  packet  service  channels  are  used  for  the  control 
and  status  signals  and  for  management  of  the  local  area  network  itself. 
Various  aspects  of  this  design  concept  are  discussed  in  the  following 
subsections. 

Network  Interface  Units 

Each  piece  of  OSCS  terminal  equipment  attaches  to  the  local  area  network 
through  a  network  interface  unit  (NIU).  Generically,  the  network  interface 
unit  in  a  LAN  provides  the  lowest  two  levels  of  the  OSI  Reference 
Architecture,  the  Data  Link  Layer  and  the  Physical  Layer.  Such  an  NIU 
presents  a  standardized  interface  to  the  local  area  network,  providing  a 
transceiver /modem  and  the  processing  power  needed  to  access  the  LAN  and 
maintain  communications  quality  (i.e.,  implement  the  link  management 
functions).  To  the  attached  equipment,  the  NIU  presents  a  compatible 
interface,  and,  if  necessary,  provides  any  packetization,  buffering, 
addressing,  and  data  handling  required  for  intercommunication  via  the  local 
area  network.  Higher  levels  of  the  OSI  architecture  are  the  responsibility 
of  the  communicating  devices — it  is  not  the  role  of  a  local  area  network 
or  a  network  interface  unit  to  insure  compatibility  between  communicating 
devices. 
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In  the  case  of  the  full  terminal  intercommunications  broadband  LAN 
envisioned  here,  the  network  interface  unit  may  be  broken  into  several 
distinct  functional  modules.  Such  a  design  would  aid  in  the  implementation 
and  deployment  of  the  network  interface  units  and  also  facilitate 
maintenance.  The  network  interface  units  for  a  particular  device  would 
then  be  made  up  of  the  appropriate  cable  driver,  cable  receiver,  packet 
service,  and  input/output  modules,  as  shown  in  Figure  5-3. 

Cable  Driver  and  Cable  Receiver  Modules.  To  support  the  LAN's  dedicated 
circuit-switched  channels,  two  distinct  modules,  a  cable  driver  and  cable 
receiver  module,  are  indicated.  Each  must  be  available  in  forms  capable  of 
supporting  either  analog  or  digital  signals  as  is  appropriate  for  the 
attached  device.  The  cable  driver  module  provides  the  transmitter  and,  in 
the  case  of  digital  communications,  modulator  needed  to  maintain  a 
dedicated  frequency  channel  on  the  broadband  cable;  the  cable  receiver 
module  provides  the  receiver/demodulator  needed  to  receive  such  channels. 
Unlike  the  cable  driver  module,  however,  the  cable  receiver  module  is 
frequency  agile,  able  to  switch  among  the  frequency  division  multiplexed 
channels.  Equipment  configuration  control  is  thus  realized  by  switching 
channels  to  that  on  which  the  desired  device  is  transmitting. 

Cable  driver  and  receiver  modules  must  be  available  in  both  analog  and 
digital  forms;  additionally,  the  data  rates/bandwidths  of  these  modules 
must  suit  the  attached  equipment — again,  different  versions  of  these 
modules  would  probably  be  the  most  cost-effective  design.  The  driver  and 
receiver  modules  interface  via  the  input/output  module  to  the  input  and 
output  ports  of  terminal  equipment,  thereby  providing  the  transparent 
equipment  intercommunications  capability  required  by  DSCS  users  of  the 
terminal  facility.  Interfaces  are  also  provided  to  the  NIU's  packet  service 
module  to  permit  communication  of  the  local  area  network's  own  control  and 
status  signals. 

Packet  Service  Modules.  Communications  on  the  shared  packet-switched 
channel (s)  are  controlled  and  implemented  by  the  NIU's  packet  service 
module.  Rather  than  employ  dedicated  multiple  channels  for  the  exchange  of 
equipment  and  LAN  control  and  status  information,  a  shared  packet-  switched 
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channel  makes  more  efficient  use  of  the  LAN's  capacity.  Either  one  or  more 
such  channels  are  possible  on  the  broadband  bus,  allowing  further  design 
flexibility.  The  example  of  Figure  5-2  shows  two  such  channels,  one  for 
LAN  management  signals  and  the  other  for  equipment  control  and  status 
signals;  Figure  5-3  accordingly  indicates  two  packet  service  modules 
composing  a  network  interface  unit  in  order  to  establish  the  two  packet 
service  channels. 

Access  to  the  packet  service  channels  may  be  controlled  by  any  of  the 
various  possible  means  available,  but  SCAN,  for  example,  uses  distributed 
access  control  in  the  form  of  CSMA/CD.  Alternatively,  it  may  be  desirable 
to  use  a  centralized  access  control  mechanism  standardized  for  all  of  the 
local  area  network's  packet  service  modules.  The  choice  of  access  control 
technique  may  be  based  on  the  control  and  status  signal  flows;  the 
broadband  bus  concept,  however,  provides  the  flexibility  to  design  any  such 
scheme  with  the  packet  service  module  providing  the  necessary  processing 
power. 

The  packet  service  module  used  for  LAN  management  interacts  directly  with 
the  other  modules  of  the  NIU,  formatting  status  information  from  the 
modules  for  communication  to  the  LAN  management  subsystem  and,  conversely, 
responding  to  packets  sent  from  the  LAN  controller.  Commands  interpreted 
by  the  LAN  management  packet  service  module  are  relayed  to  the  NIU's  cable 
receiver  module  to  control  selection  of  the  received  circuit-switched 
channel  and  thereby  establish  the  equipment  connectivity  and  terminal 
configuration.  Central  monitoring  of  the  local  area  network  may  also  lead 
to  a  command  for  all  stations  to  switch  to  a  redundant  secondary  cable; 
again,  the  packet  service  module  must  respond  to  such  local  area  network 
control  commands  and  interface  with  the  other  NIU  modules  appropriately. 

Input/Output  Modules.  Since  existing  OSCS  terminal  equipment  has  typically 
been  designed  for  interconnection  through  conventional  patch  panels,  the 
input/output  module  provides  the  necessary  interfaces  between  the  attached 
device  and  the  other  modules  of  the  NIU.  The  equipment  input/output  ports 
may  require  conversion  from  one  electrical  and  physical  interface  standard 
to  another  while  the  equipment  control  and  status  signals  may  require 
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POSSIBLE  NETIJORK  INTERFACE  UNIT  MODULES 


•  CABLE  DRIVER  MODULE 

-  FIXED  FREQUENCY  TRANSMISSION 

-  PROVIDES  DEDICATED  BROADBAND  CHANNEL 

•  CABLE  RECEIVER  MODULE 

-  FREQUENCY  AGILE 

-  PROVIDES  EQUIPMENT  CONFIGURATION  CONTROL  (SWITCHING) 

•  PACKET  SERVICE  MODULE 

-  SUPPORTS  SHARED  CHANNEL  PACKET  SWITCHING 

-  IMPLEMENTS  MEDIA  ACCESS  AND  DATA  LINK  LEVEL  PROTOCOLS 

-  SUPPORTS  NETWORK  CONTROL  RESPONSIBILITIES 

•  INPUT/OUTPUT  MODULE 

-  IMPLEMENTS  INTERFACES  BETWEEN  DSCS  TERMINAL  EQUIPMENT 
AND  OTHER  MODULES 
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special  handling  to  permit  their  communication  via  packet-switching.  In 
some  cases,  the  I/O  module  must  possess  the  processing  capability  to  format 
and  address  (packetize)  control  and  status  signals  sent  from  a  particular 
equipment  and,  conversely,  to  de-packetize  received  data.  For  those 
devices  not  currently  permitting  remote  control  and  status  interfacing,  the 
I/O  module's  capabilities  might  be  extended  to  allow  the  emulation  of  the 
device  front  panel  functions.  The  I/O  module  thus  presents  an  appropriate 
interface  to  both  the  attached  equipment  and  the  other  NIU  modules  and,  in 
the  case  of  control  and  status  signals,  mediates  between  the  data  format 
required  by  the  local  area  network  and  that  required  by  the  device.  Given 
the  possible  wide  range  of  I/O  module  responsibilities  and  the  need  to 
accommodate  all  the  ports  of  the  attached  device,  the  I/O  module  itself 
might  be  constructed  in  modular  form. 

As  an  example  of  the  types  of  physical  interfaces  that  must  be  supported  by 
the  NIU  I/O  modules.  Table  5-2  documents  the  interfaces  supported  by  SCAN 
for  the  packet  and  circuit  service  channels.  The  indicated  wide  range  of 
interfaces  is  not  handled  by  any  single  module,  but  rather  by  different 
versions  of  SCAN’s  I/O  and  cable  driver/receiver  modules.  Due  to  the 
disparate  nature  of  the  current  OSCS  terminal  equipment,  the  network 
interface  units  of  any  local  area  network  introduced  into  the  terminal  will 
be  required  to  support  a  similar  variety  of  interfaces. 

Modular  Construction  of  the  NIU.  The  connection  of  a  device  to  the  full 
intercommunications  LAN  thus  involves  the  selection  and  assembly  of  the 
appropriate  NIU  modules:  the  I/O  module(s)  accommodating  the  equipment's 
particular  input,  output,  and  control  and  status  ports  must  be  chosen  as 
must  either  digital  or  analog  versions  of  the  cable  driver  and  receiver 
modules.  A  cable  driver  module  is  needed  for  each  output  of  any  single 
piece  of  equipment;  a  cable  receiver  module  is  needed  for  each  equipment 
input.  The  design  of  the  modules  might  possibly  be  based  on  a  shared  power 
and  interface  bus  so  that  PC-cards  corresponding  to  each  module  may  readily 
be  replaced  and  interchanged  in  a  standard  NIU  chassis.  Ideally,  the 
functions  of  the  NIU  would  be  incorporated  into  the  design  of  future  DSCS 
terminal  equipment,  but  as  of  now  it  is  unlikely  that  the  NIU  modules  may 
even  draw  power  from  the  attached  device. 
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MIL-ST0-1397A 
MIL-STD-1397A/B/C 
MIL-STD-1397D/E 
MIL-STD-1553B* 
IEEE  488  (GPIB)* 


TABLE  5-2 

SCAN  EQUIPMENT  INTERFACES 
PACKET  SERVICE  INTERFACES  (I/O  MOOULESl 

PARALLEL,  41667  UPS 
PARALLEL.  250  KWPS 
SERIAL.  10  MBPS 
SERIAL.  1  MBPS 
PARALLEL.  1  MWPS 


MIL-STD-188-114/100  ELECTRICAL  CHARACTERISTICS 

RS-232C  75.  150.  300.  600.  1200. 


RS-422A 


RS-423A 


RS-449 


20  CURRENT  LOOP 


2400.  4800.  9600.  19200  BPS 


75.  150.  300.  600.  1200. 
2400.  4800.  9600.  56000  BPS 


75.  150.  300.  600.  1200. 
2400.  4800.  9600.  56000  BPS 


75.  150.  300.  600.  1200. 
2400.  4800.  9600.  19200. 
56000.  112000.  224000  BPS 

50.  75.  150  BAUD/SEC 


CIRCUIT  SERVICE  INTERFACES  (CABLE  DRIVER/RECEIVER  MODULES 


MIL-STD-1397A/B/C/D/E 

MIL-ST0-1553B* 

RS-232C 

RS-422A 

RS-423A 

MIL-STD-188-100  ANALOG 


NIU  PROVIDES  BUS  CONTROL  OF  POLLED  BUS  INTERFACE. 
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Final  installation  of  a  device  is  accomplished  once  the  transmit 
frequencies  of  the  NIU's  cable  driver  modules  (assuming  more  than  one 
device  output)  are  logged  with  the  LAN  controller  and  the  NIU's  cable 
receiver  modules  and  those  of  other  NIU's  are  commanded  to  establish  the 
desired  connectivity. 

LAN  Management 

The  control  of  the  full  intercommunications  LAN  is  the  responsibility  of 
the  LAN  management  subsystem.  Under  operator  control,  such  a  controller 
should  provide  rapid  display  of  the  local  area  network  status,  exhibit  the 
existing  connectivities,  and  allow  control  of  all  LAN  functions.  A 
database  of  the  equipment  connections,  associated  NIU  capabilities,  and 
circuit  service  channel  assignments  must  be  maintained  and  the  means  to 
transmit  control  packets  instructing  the  cable  receiver  modules  to  switch 
frequencies  must  be  supported.  Ideally,  the  subsystem  would  provide  a 
user-friendly  interface,  allowing  easy  understanding  of  the  equipment 
configurations  implied  by  the  channel  assignments  and  providing  assistance 
in  establishing  new  configurations,  especially  to  warn  the  operator  of 
improper  or  inappropriate  connections. 

Classified/Unclassified  Data 


Earth  terminal  intercommunications,  either  at  a  Network  Control  Terminal  or 
Network  Terminal,  involves  the  handling  of  classified  data.  At  a  Network 
Control  Terminal,  the  signal  quality  data  for  a  particular  link  is  not 
classified,  but  the  aggregate  of  such  data  for  many  Network  Terminals  is 
considered  classified.  At  Network  Terminals,  DSCS  network  configuration 
data  is  classified  while  equipment  status  and  control  information  is 
unclassified.  OSCS  user  communications  are  not  classified  since  it  is 
assumed  that  the  users  themselves  are  responsible  for  the  encryption  of  any 
secure  communications;  configuration  definition  data  received  over  the 
Critical  Control  Circuits,  however,  is  classified. 
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Relay  of  classified  (red)  data  must  be  within  a  designated  red  area  of  the 
terminal  and,  except  for  terminals  within  the  DSCS  Operations  Center,  must 
be  supported  by  devices  which  are  TEMPEST  qualified.  If  classified  data  is 
to  be  supported  by  a  local  area  network,  that  LAN  must  fulfill  such 
requirements.  Neither  TDMA  or  FDMA  reservation  schemes  supported  on  a  bus 
topology  can  satisfy  these  communications  security  requirements,  indicating 
that  a  second,  independent  full  interconmtuni cat ions  LAN  is  needed  to 
support  red  data.  This  LAN  would  not  have  to  support  the  same  aggregate 
throughput  as  the  black  full  intercommunications  LAN,  but  it  should  support 
the  intra-terminal  relay  of  decrypted  Critical  Control  Circuits.  In  order 
to  prevent  classified  data  from  entering  a  black  area,  the 
intercommunication  of  data  between  red  and  black  LAN's  must  be  protected  by 
Line  Guardian  Units  and/or  encryptors/decryptors. 

LAN  Access  and  Terminal  Configurations 

If  the  full  intercommunications  LAN  concept  is  to  be  applied,  two  distinct 
LAN  access  approaches  are  possible.  User  signals  interface  to  the  OSCS 
network  through  the  Technical  Control  Facility  which  provides  the  necessary 
interface  equipment.  The  DSCS  user  signals  are  then  typically  presented  to 
the  Digital  Communications  Subsystem  (DCSS)  through  the  Main  Distribution 
Frame.  Either  these  signals  may  be  each  connected  to  NIU's  and  directed  to 
the  appropriate  DCSS  equipment  through  the  broadband  LAN  (as  shown  in  the 
example  of  Figure  5-2)  or  they  may  be  routed  by  cable  directly  to  the  first 
stage  of  DCSS  equipment  which,  in  turn,  is  connected  to  other  DCSS 
equipment  via  the  local  area  network.  The  two  approaches  have  their 
advantages  and  disadvantages;  either  alternative  may  be  pursued  without 
significantly  affecting  the  design  concept,  although  the  choice  does 
somewhat  alter  the  way  in  which  the  local  area  network  accommodates  a 
particular  terminal  configuration. 
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Direct  User  Access.  The  first  technique,  direct  user  access  to  the 
intercommunications  LAN,  involves  many  NIU's  and  may  require  special 
consideration  of  non-standard  equipment  interfaces  to  Technical  Control 
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Facility  devices.  Since  user  channels  are  typically  multiplexed  in  the 
DCSS,  the  number  of  user  channels  is  greater  than  the  number  of  equipment- 
to-equipment  channels  and  hence  the  need  for  many  more  NIU's  and  broadband 
LAN  channels.  If  user  channels  are  given  channels  on  the  LAN,  however,  the 
wide  range  of  data  rates  may  lead  to  a  complicated,  expensive  NIU  design  in 
addition  to  requiring  many  more  of  them. 

Equipment-to-Equipment  Interconnections  Only.  If  the  LAN  only  supports 
equipment-to-equipment  interconnections  within  the  DCSS,  on  the  other  hand, 
the  ability  to  control  equipment  configurations  and  the  flow  of  user 
signals  through  the  terminal  would  be  limited  to  just  those 
interconnections  supported  by  the  LAN — the  connections  between  user 
circuits  in  the  Technical  Control  Facility  and  the  first  stage  of  DCSS 
equipment  would  not  be  controllable  by  the  LAN.  The  problem  of  interfacing 
to  the  local  area  network,  however,  becomes  simplified.  Existing  earth 
terminal  devices  or,  ideally,  some  other  equipment  providing  a  remote 
configuration  control  capability  would  be  used  as  the  user  interface.  In 
this  regard,  the  possibility  of  a  hybrid  LAN/IMPAT  design  might  be 
considered. 

Hybrid  LAN/IMPAT.  The  Integrated  Multiplex,  Patch,  and  Test  (IMPAT) 
equipment  discussed  at  length  in  Section  6  of  this  report  might  be  employed 
as  a  user  circuit  interface  to  a  full  intercommunications  LAN.  User 
circuits  would  still  be  supported  via  a  local  area  network,  but  the  task  of 
user  circuit  access  to  the  LAN  would  be  simplified  by  using  the  IMPAT.  The 
IMPAT  provides  an  electronic  patch  capability,  able  to  dynamically  switch 
input  and  output  connections,  and  also  performs  a  variety  of  multiplexer 
functions,  including  the  emulation  of  existing  DCSS  multiplexers.  User 
circuits  might  thus  connect  to  IMPAT  devices  as  the  first  stage  of  DCSS 
equipment  and  then,  after  any  appropriate  multiplexing,  be  interfaced  (via 
NIU's)  to  the  full  intercommunications  LAN.  The  advantage  realized  through 
using  the  IMPAT  in  this  way  is,  first,  the  reduction  in  the  number  of  NIU's 
required  to  interface  to  the  LAN,  and,  second,  the  ability  to  control  user 
circuit  connections  to  the  first  stage  of  DCSS  equipment  through  the 
IMPAT' s  electronic  patch  capability. 
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OSCS  Terminal  Configurations.  Four  different  DSCS  terminal  configurations 
are  possible,  as  discussed  in  Section  3  and  shown  in  Figure  5-4.  The 
differences  among  these  configurations  must  be  addressed  by  any  terminal 
local  area  network  design.  Case  III  defines  the  simplest  configuration  in 
which  the  Technical  Control  Facility  and  the  Earth  Terminal  are  located  in 
the  same  facility.  The  full  intercommunications  LAN  may  then  support  user 
signals  either  at  the  interface  between  the  Technical  Control  Facility  and 
the  Digital  Communications  Subsystem  or  after  the  first  stage  of  OCSS 
processing,  as  discussed  above. 

In  the  other  three  cases,  the  Technical  Control  Facility  and  Earth  Terminal 
are  in  separate  facilities,  transparently  linked  by  the  Interconnect 
Facility  (ICF)  via  coaxial  or  fiber-optic  cable  or  line-of-sight  microwave 
transmission.  Cases  II  and  IV  are  alike  in  that  elements  of  the  DCSS  are 
present  in  both  facilities;  in  Case  I,  the  DCSS  is  only  in  the  Earth 
Terminal  facility.  In  Case  I,  then,  the  full  intercommunications  LAN  need 
only  be  provided  in  the  Earth  Terminal  facility,  interfacing  to  the  Earth 
Terminal's  Interconnect  Facility.  The  role  of  the  Interconnect  Facility  is 
to  collect  and  distribute  terminal  signals  in  support  of  their 
intercommunication  between  the  two  separate  terminal  facilities;  in  Case  I, 
the  signals  at  the  ICF  are  effectively  the  DSCS  user  signals. 

In  Cases  II  and  IV,  however,  the  full  intercommunications  LAN  should 
support  intercommunications  in  both  facilities.  Use  of  point-to-point 
links  to  connect  cable  segments  in  a  local  area  network  is  not  at  all 
exceptional.  Typically,  the  only  constraint  on  such  links  is  due  to  the 
possible  effects  of  propagation  delay  on  the  effective  operation  of  the 
LAN's  access  control  protocol.  In  the  full  intercommunications  LAN 
discussed  here,  only  the  packet-switched  channels  would  be  subject  to  such 
limitations,  and  even  then  the  access  control  technique  may  be  designed  to 
account  for  the  worst-case  end-to-end  propagation  delays  envisioned.  The 
point-to-point  link  between  facilities  may  take  advantage  of  the  full 
intercommunication  LAN's  frequency  division  multiplexing  or  the 
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multiplexing  scheme  of  an  existing  Interconnect  Facility  may  be  used.  The 
latter  possibility  is  not  particularly  attractive  since  it  requires  the 
multiplexing/demultiplexing  of  the  entire  broadband  bus,  but  it  is 
possible:  the  Interconnect  Facility  would  be  effectively  treated  as  a 
single  device  supported  by  the  full  intercommunications  LAN  with 
connections  to  all  other  devices. 

Reliability  and  Cost 


While  the  discussion  of  the  full  interconsnunications  LAN  has  thus  far 
concerned  the  satisfaction  of  functionality  and  flexibility  requirements, 
the  representative  design  concept  of  a  broadband  LAN  al'ows  some  initial 
comments  to  be  made  concerning  reliability  and  cost. 

Reliability.  The  reliability  of  any  local  area  network  may  be  assessed 
from  two  points  of  view:  the  reliability  of  the  hardware/software  (i.e., 
the  network  interface  unit)  used  to  connect  a  particular  device  to  the 
local  area  network  and  the  reliability  of  the  LAN  as  a  whole  in  maintaining 
its  functionality  in  the  event  of  the  failure  of  a  particular  attached 
device  and/or  its  network  interface  unit.  These  two  points  of  view  are 
most  distinct  in  decentralized  systems  where  the  network  interface  units 
are  fairly  complex  in  order  to  control  the  working  of  the  LAN  in  a 
I  distributed  fashion.  Depending  on  the  exact  system  implementation,  the 

network  interface  units  may  be  somewhat  less  complex  in  a  centralized  LAN, 
but  performance  is  dependent  on  fault-free  operation  of  the  central  LAN 
controller.  In  any  design  of  a  full  intercommunications  LAN,  distributed 
control  is  a  desirable  attribute  to  enhance  reliability. 

[ 

In  the  local  area  network  proposed  here  as  representative  of  a  full 
intercommunications  LAN,  control  is  distributed:  network  interface  units 
provide  the  transceiving  and  processing  capabilities  needed  to  access  the 
broadband  cable  plant  and  control  LAN  operation.  There  is  centralized 
control  in  the  sense  that  the  LAN  management  subsystem  co-ordinates 
-  connectivity  through  the  assignment  of  channels,  but  it  is  w,  e  individual 
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NIU's  which,  in  response  to  such  commands,  actually  effect  the  working  of 
the  local  area  network.  Depending  on  the  actual  design,  the  LAN,  once 
configured,  could  maintain  performance  even  in  the  event  of  failure  of  the 
LAN  management  subsystem.  The  ability  to  control  equipment  configurations, 
of  course,  would  be  lost  while  repairs  are  made  or  a  backup  management 
subsystem  brought  on-line. 

The  support  of  full  DSCS  terminal  intercommunications  by  a  local  area 
network  is  necessarily  more  complicated  than  simply  using  patch  cords  and  a 
manual  patch  panel — the  network  interface  units  required  for  each  attached 
piece  of  equipment  represent  fairly  sophisticated  devices  in  themselves. 
Failure  of  an  NIU  is  thus  a  very  real  possibility,  although  hopefully  the 
NIU  design  would  disallow  failures  which  cause  the  NIU  to  jam  and  disrupt 
the  local  area  network.  Failure  of  an  NIU  is  effectively  the  same  as  the 
failure  of  its  associated  equipment — the  user  circuit  supported  by  the 
affected  equipment  chain  is  broken.  Once  the  source,  of  the  failure  is 
identified,  however,  redundant  equipment  may  be  switched  on-line  as  long  as 
the  local  area  network  itself  is  still  operational.  The  full 
intercommunications  LAN  design  concept  presented  here  reflects  the  desire 
for  LAN  reliability:  a  coaxial  bus  readily  tolerates  the  failure  of 
attached  devices  without  affecting  the  other  working  components.  Other 
designs,  of  course,  may  be  similarly  capable  of  providing  fail-safe  local 
area  network  operation. 

Cost.  No  precise  estimate  of  the  cost  of  a  full  intercommunications  LAN 
for  the  DSCS  earth  terminals  is  possible  at  this  stage — only  issues  and 
concepts  have  been  presented,  not  a  complete  design.  Nonetheless,  some 
conjectures  may  be  advanced.  While  the  costs  of  the  LAN  transmission  media 
and  the  local  area  network's  installation  are  non-trivial  items,  the  major 
costs  are  involved  in  the  network  interface  units  required  to  link  each 
terminal  device  to  the  local  area  network.  Costs  of  the  NIU's  may  be 
categorized  as  either  development  or  unit  costs.  Development  costs  will  be 
incurred  if  the  full  intercommunications  LAN  design  cannot  be  fulfilled 
using  existing  equipment  and  components  but  instead  requires  the  design  and 
development  of  new  devices;  unit  costs  are  here  interpreted  as  the 
production  costs  of  each  NIU  after  the  development  phase. 
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Development  costs  reflect  the  effort  involved  in  designing  the 
software/hardware  needed  to  implement  the  envisioned  network  interface 
units.  In  the  case  of  the  full  intercommunications  LAN  discussed  here,  no 
product  is  presently  commercially  available  which  provides  the  needed 
connectivities  and  data  rates.  The  technology  to  implement  a  full 
intercommunications  LAN  is  not  out  of  reach  of  current  capabilities — it  is 
merely  a  question  of  applying  existing  and  well-known  technology  to  the 
specific  task.  The  I/O  modules  will  especially  require  attention  since  they 
must  perform  the  interface  conversion  between  the  various  terminal  devices 
and  the  local  area  network.  And  further  design  efforts  are  necessary  if 
the  I/O  modules  are  to  provide  remote  control  and  status  monitoring 
features  for  devices  which  do  not  themselves  provide  such  capabilities.  As 
a  very  rough  estimate,  the  development  cost  for  each  of  the  four  modules 
may  be  between  $100,000  and  $500,000.  Development  costs,  although 
ostensibly  high,  may  be  distributed  over  the  number  of  devices  produced, 
thereby  somewhat  limiting  the  cost  impact.  Furthermore,  development  costs 
may  be  significantly  defrayed  if  an  effort  is  made  to  use  as  much 
commercially  available  equipment  as  possible;  this  approach  has  been 
followed  in  the  implementation  of  the  Modular  Building-Block  Data  Bus  in 
order  to  speed  delivery. 

Unit  costs  reflect  the  manufacturing  expenses  involved  in  producing  the 
NlU's.  The  cost  of  commercial  NIU's  range  from  approximately  $200  (for 
circuit  board  implementations)  to  tens  of  thousands  of  dollars  for  more 
complex  stand-alone  units.  Although  the  NIU  modules  described  as 
representative  of  those  needed  in  a  full  intercommunications  LAN  do  not 
have  identical  capabilities,  assume,  as  a  first  approximation,  that  the  NIU 
modules  each  cost  $1500,  with  the  cost  of  the  NIU  chassis  distributed  over 
the  four  different  modules.  This  figure  is  consistent  with  the  estimated 
costs  of  elements  of  the  Modular  Building-Block  Data  Bus;  according  to 
conversations  with  Col.  Fred  Albertson,  that  system's  Bus  Interface  Unit 
used  for  handling  digital  data,  for  example,  is  estimated  at  $2000,  while 
the  off-the-shelf  10  Mbps  COMTEC  frequency-agile  modem  used  in  the  system 
costs  approximately  $1400-1500. 
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In  the  example  full  intercommunications  LAN  considered  here,  a  cable  driver 
module  is  required  for  every  equipment  output,  a  cable  receiver  module  is 
required  for  every  input,  and  for  each  device  one  I/O  module  and  two  packet 
service  modules  are  assumed,  in  keeping  with  the  illustration  of 
Figure  5-3.  Other  NIU  configurations  are  of  course  possible:  more  than 
one  I/O  module  might  be  required  per  device  if  they  are  each  designed  for  a 
limited  number  of  ports;  one  or  two  packet  service  modules  may  be  used 
depending  on  the  number  of  packet  service  channels  on  the  LAN;  the  cable 
driver  and  receiver  modules  might  be  designed  to  support  multiple  channels, 
thereby  reducing  the  number  of  modules  required;  and/or  the  NIL)  design 
might,  while  retaining  modularity,  share  processing  or  transceiving 
capabilities  among  modules.  For  the  purposes  of  this  discussion,  however, 
the  initially  stated  assumptions  apply. 

Table  C-4  of  Appendix  C  lists  the  maximum  number  of  input  and  output  ports 
for  various  terminal  devices  and  provides  estimates  of  the  number  of 
devices  (both  active  and  redundant)  employed  in  the  baseline  light,  medium, 
and  heavy  terminals.  Employing  the  data  of  Table  C-4,  Table  5-3  then 
provides  an  estimate  of  the  number  of  NIU  modules  required  for  the  various 
equipment  types  and  for  the  user  circuits  specified  in  Table  3-1.  Since 
the  maximum  number  of  I/O  ports  is  assumed,  the  estimated  number  of  modules 
is  somewhat  inflated,  but,  nonetheless,  the  subtotals  and  totals  indicated 
in  Table  3-1  provide  some  measure  of  the  full  intercommunications  LAN 
requirements.  The  subtotals  refer  to  the  number  of  modules  needed  if  user 
circuits  are  patched  to  the  first  stage  of  multiplexing:  with 
approximately  374,  1609,  and  2442  modules  needed  for  light,  medium,  and 
heavy  terminals,  respectively,  the  corresponding  NIU  expense  per  terminal 
is  approximately  $561,000,  $2,413,500,  and  $3,663,000,  depending  on  the 
terminal  size.  If  user  circuits  are  introduced  directly  to  the  LAN,  then  an 
additional  number  of  NIU's  are  required.  It  is  assumed  that  the  NIU's  used 
for  this  purpose  will  not  require  an  I/O  module  or  a  packet  switch  module 
for  equipment  control  and  status  signalling,  but  will  merely  use  a  cable 
driver  and  cable  receiver  module  and  a  packet  service  module  to  control  the 
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TABLE  5-3 

ESTIHATEO  NUMBER  OF  NIU  MODULES 


EQUIPMENT  TYPE 


ECCM  R/T  UNITS 


1002  R/T  UNITS 


MODULE  TYPE 


SUBTOTALS 


USER  CIRCUITS 
(SEE  TABLE  3-1) 


TOTALS 


ABLF  DRIVER 


PACKET  SERVICE 


NUMBER  REQUIRED  PER  TERMINAL  TYPE 
LIGHT  MEDIUM  HEAVY 


14 


CABLE  RECEIVER 


lyo 


PACKET  SERVICE 


CABLE  RECEIVER 


PACKET  SERVICE 


zn 


1  PACKET  SERVICE 

6 

50 

1  CABLE  RECEIVER 

50 

PACKET  SERVICE 


CABLE  DRIVER 


CABLE  RECEIVER 


mvrnmmi 

lil 


PACKET  SERVICE 

40 

SUBTOTAL 

374 

CABLE  RECEIVER 


I/O 


PACKET  SERVICE 


CABLE  DRIVER 


CABLE  RECEIVER 


TOTAL 

728 

3,295 

4,728 
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NIL!  itself.  The  number  of  modules  required  is  then  significantly 
greater:  approximately  728,  3295,  and  4728  modules  are  needed  for  light, 
medium,  and  heavy  terminals,  respectively,  indicating  a  corresponding  NIU 
expense  of  $1,092,000,  $4,942,500,  and  $7,092,000. 

Observations 


The  full  DSCS  terminal  intercommunications  LAN  concept  presented  here 
attempts  to  reconcile  the  conflicting  needs  of  DSCS  dedicated  user  circuits 
with  LAN  technology.  Local  area  networks  are  typically  constructed  to 
support  peer-to-peer  or  master-slave  data  communications — the  dedicated 
"through"  communications  characteristic  of  a  DSCS  earth  terminal  are  not 
normally  addressed  by  LAN  technology  and  approaches.  Nonetheless,  the 
Navy's  SCAN  provides  a  precedent  in  supporting  such  dedicated  circuit- 
switched  communications  with  a  local  area  network  and  serves  as  an  example 
in  demonstrating  the  capabilities  required  to  support  full  terminal 
i ntercommun i cat i ons . 

In  the  Navy's  intended  application,  however,  the  physical  dispersal  of 
communications  equipment  on-board  ship  justifies  the  introduction  of  LAN 
technology.  For  the  DSCS  earth  terminals,  often  all  equipment  is  in  one 
shelter.  The  network  interface  units  required  to  support  the  connection  of 
terminal  equipment  to  the  full  intercommunications  LAN  may  involve  a  single 
board  added  to  the  equipment  or,  more  likely,  may  require  a  full  rack 
shelf.  The  introduction  of  such  network  interface  units  may  thus  possibly 
demand  an  inordinate  amount  of  scarce  rack  and  shelter  space  in  comparison 
to  the  space  conserved  by  the  replacement  of  the  current  manual  patch 
panels.  And  the  network  interface  units  themselves  represent  a  fairly 
complex  technology  compared  to  the  use  of  patch  panels — the  estimated  NIU 
costs  per  terminal  represent  a  considerable  investment. 

On  the  other  hand,  use  of  a  full  terminal  intercommunications  LAN  would 
simplify  the  installation  of  a  terminal  and  eliminate  most  if  not  all  of 
the  distribution  frames  and  patch  panels  currently  employed.  The  LAN  is 
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consistent  with  the  desire  for  remote  control  and  access  capabilities  and, 
as  discussed  in  the  next  section,  can  actively  support  a  wide  range  of 
control  concepts.  Possibly  the  most  significant  feature,  however,  is 
provided  by  the  capabilities  implicit  in  use  of  the  LAN  for  terminal 
configuration  control.  A  LAN  management  subsystem  was  speculated  in  a 
previous  subsection  as  a  means  of  controlling  the  LAN  connectivities  and 
hence  the  terminal  configuration — a  user-friendly  such  system  would  speed 
the  error-free  set-up  of  terminal  configurations  and  reduce  the  demands 
made  upon  terminal  personnel.  The  potential  savings  in  time  and,  perhaps, 
staffing  might  offset  the  development  and  deployment  costs. 

The  design  of  a  full  intercommunications  LAN  for  DSCS  earth  terminals  is 
thus  feasible,  but  may  not  provide  a  cost-effective  approach  to  terminal 
subsystem  integration. 
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5.3  CONTROL  AND  STATUS  LAN 


Introduction 


A  control  and  status  LAN  for  the  DSCS  earth  terminals  must  support  the 
intercommunication  of  control  and  status  signals  between  DSCS  terminal 
equipment  and  subsystems  and  the  terminal's  control  and  status  monitor 
processor(s) .  A  control  and  status  LAN  is  not  intended  to  support  the 
relay  of  user  signals  through  the  terminal — that  interconnect  function  is 
assumed  to  be  performed  by  some  other  means.  The  number  and  variety  of 
signals  to  be  handled  by  the  control  and  status  LAN  is  thus  quite  less  than 
in  a  full  intercommunications  LAN.  The  communication  of  control  and  status 
signals  between  devices — because  dedicated  channels  are  not  required  and 
low  data  rates  are  involved — closely  corresponds  to  the  type  of 
communications  typically  served  by  local  area  networks.  Consequently, 
commercial,  off-the-  shelf  local  area  network  technology  may  be  suitable. 
The  desired  connectivity  and  communications  flows  must  be  known,  however, 
in  order  to  determine  the  most  appropriate  local  area  network  design. 

Some  of  the  existing  DSCS  subsystems — for  example,  the  DSCS  ECCM  Control 
Subsystem  (DECS)  and  the  DSCS  FDM  Control  Subsystem  (DECS)  —  involve  a 
processor  which  communicates  with  the  subsystem's  associated  equipment 
directly.  The  communications  are  established  via  interfaces  such  as  RS- 
449,  RS-232-C,  or  the  IEEE  488  bus.  Unfortunately,  current  DSCS  devices  do 
not  adhere  to  any  one,  single  interface  standard.  If  these  devices  are  to 
be  directly  connected  to  a  control  and  status  LAN,  a  network  interface  unit 
for  each  device  would  be  required  to  perform  the  necessary  physical  and 
data  link  layer  interfacing.  Future  OSCS  equipment,  however,  might  include 
standardized  control  and  status  LAN  interfaces,  incorporating  the  functions 
of  a  network  interface  unit  into  the  device. 

The  development  of  a  control  and  status  LAN  for  the  DSCS  earth  terminals 
can  be  seen  as  part  of  an  overall  effort  to  integrate  the  various  terminal 
subsystems  and  equipment.  The  preliminary  MIST  design,  for  example. 
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CONTROL  AND  STATUS  LAN:  INTRODUCTION 


SUPPORTS  INTERCOfMUNICATION  OF  CONTROL  AND  STATUS  SIGNALS  BETWEEN 
DSCS  TERMINAL  EQUIPMENT  AND  CONTROL/STATUS  MONITOR  PROCESSOR(S) 

DOES  NOT  SUPPORT  INTERCONNECTION  OF  DEVICES  FOR  RELAY  OF  USER 
COMMUNICATIONS  THROUGH  TERMINAL 


•  SOME  EXISTING  SUBSYSTEMS  (E.G..  DECS.  DECS)  PROVIDE  SELF-CONTAINED 
CONTROL/STATUS  COMMUNICATION  CAPABILITIES 

-  TYPICAL  EQUIPMENT  INTERFACES: 

—  DECS/LRM:  RS-449 
—  DECS/USC-28:  RS-232-C 
—  MX-9922/0FCS:  IEEE  488 

i  FUTURE  USE  OF  CENTRAL  PROCESSOR  IN  MIST  AS 

-  CONTROLLER 

-  STATUS  MONITOR 

•  FUTURE  SUBSYSTEMS  MAY  PROVIDE  STANDARDIZED  C&S  LAN  INTERFACES 
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specifies  a  central  processor  to  be  used  as  controller  and  status  monitor 
of  the  terminal  equipment.  The  design  of  a  control  and  status  LAN  to 
support  such  a  concept  will  depend  on  the  planned  role  of  such  a  central 
controller/monitor.  Two  fundamental  connectivity  strategies  for  the  control 
and  status  LAN  are  seen  as  likely  candidates,  each  approach  making 
different  assumptions  as  to  the  nature  of  the  control  and  status  monitoring 
system.  Neither  of  the  two  approaches,  however,  leads  to  a  specific  LAN 
design.  Unlike  the  situation  in  considering  the  local  area  network  support 
of  full  terminal  intercommunications,  no  one  issue  narrows  the  number  of 
possible  alternatives — the  communications  problem  admits  many  of  the 
solutions  provided  by  the  various  local  area  network  options.  As  a 
consequence,  the  ultimate  choice  of  local  area  network  technology  need  not 
be  custom-  designed,  but  may  take  advantage  of  existing  products. 

Connectivity  Strategies 

The  control  and  status  monitor  functions  and,  more  importantly,  the 
distribution  of  those  functions,  will  determine  how  best  to  design  the 
control  and  status  local  area  network.  Two  LAN  connectivity  strategies  are 
apparent,  each  reflecting  different  philosophies  in  the  terminal  control 
and  status  monitor  capabilities. 

Connection  of  All  Terminal  Equipment.  One  concept  of  the  control  and 
status  LAN  assumes  that  all  terminal  equipment  will  be  directly  connected 
to  the  local  area  network,  as  in  the  full  intercommunications  LAN.  The 
relay  of  equipment  control  and  status  signals  will  be  supported  by  the  LAN, 
replacing  the  existing  intra-subsystem  connections  between  subsystem 
processors  and  supported  equipment.  Communications  between  the  various 
terminal  devices  and  the  subsystem  processors  and  any  central 
control /monitor  processor  will  be  through  the  LAN.  Figure  5-5  illustrates 
in  an  abstract  fashion  how  each  device  communicates  to  the  central 
processor  and,  if  appropriate,  to  its  subsystem  processor.  The  figure  is 
not  meant  to  suggest  that  a  star  topology  is  the  only  possible  LAN 
configuration,  but  merely  illustrates  the  communication  flows  and 
functional  responsibilities. 
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CONTROL  AND  STATUS  LAN;  CONNECTIVITY  STRATEGIES 


•  LAN  DESIGN  REFLECTS  ROLE  OF  CENTRAL  CONTROLLER/MONITOR 

•  INTERCOMMUNICATION  OF  CONTROL  AND  STATUS  DATA  FROM  ALL  TERMINAL 
EQUIPMENT  (E.G.,  FULL  INTERCOMUNICATIONS  LAN) 

-  EQUIPMENT  C/S  SIGNALS  COMftiNICATED  TO/FROM  CENTRAL  PROCESSOR 
AND/OR  SUBSYSTEM  PROCESSOR(S)  VIA  LAN 

-  LAN  REPLACES  EXISTING  INTRA-SUBSYSTEM  CONNECTIONS 

-  THIS  APPROACH  SUPPORTS  POSSIBLE  ASSUMPTION  OF  ALL  SUBSYSTEM 
CONTROL/MONITOR  RESPONSIBILITIES  BY  CENTRAL  PROCESSOR, 
ELIMINATING  SUBSYSTEM  PROCESSORS 

•  INTERCOMMUNICATION  BETWEEN  CENTRAL  PROCESSOR  AND  SUBSYSTEM 
PROCESSORS  ONLY 

-  PEER-TO-PEER  COMMUNICATIONS  BETWEEN  PROCESSORS  VIA  LAN 

-  SUBSYSTEM  PROCESSOR/EQUIPMENT  INTERCONNECTIONS  NOT  SUPPORTED 
BY  LAN;  EXISTING  C/S  INTERCONNECTIONS  MAINTAINED 

-  SUBSYSTEM  PROCESSORS  MAY  RETAIN  CURRENT  ROLES;  CENTRAL 
PROCESSOR  USED  IN  SUPERVISORY  MODE  AND/OR  TO 
COLLECT/DISTRIBUTE  DATA 

-  ALTERNATIVELY,  SUBSYSTEM  PROCESSORS  MAY  ACT  AS  INTELLIGENT 
EQUIPMENT  INTERFACES  SUBORDINATE  TO  CENTRAL  PROCESSOR 
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Since  the  control  and  status  LAN  described  here  supersedes  all  intra¬ 
subsystem  connections^  such  a  concept  lends  itself  well  to  the  assumption 
of  all  control  and  monitor  responsibilities  by  the  central  processor.  In 
that  case,  the  subsystem  processors  are  eliminated,  their  roles  taken  over 
by  the  central  processor.  If  that  is  indeed  the  function  of  the  central 
processor,  then  a  star  topology  probably  does  best  serve  the  communications 
requirements.  Alternatively,  if  the  subsystem  processors  are  retained, 
then  a  ring  or  bus  LAN  topology  might  be  more  suitable  in  supporting  the 
control  and  status  signal  flows. 

Connection  of  Subsystem  Processors.  The  presence  of  the  subsystem 
processors  suggests  a  second  connectivity  strategy  for  the  control  and 
status  LAN.  Since  the  subsystem  processors  already  interface  to  their 
associated  equipment,  the  control  and  status  LAN  may  be  used  to  support 
intercommunications  between  the  central  processor  and  subsystem  processors 
only.  The  resulting  peer-to-peer  communications  between  processors  is  the 
type  of  communications  addressed  by  most  commercially  available  LAN's. 

This  control  and  status  LAN  concept  is  represented  by  the  abstraction  of 
Figure  5-6,  showing  also  how  some  terminal  devices  may  communicate  directly 
to  the  central  controller/monitor  if  they  are  not  supported  by  a  subsystem 
processor. 

This  second  approach  to  the  control  and  status  LAN  design  suggests  two 
extreme  roles  for  the  central  processor.  In  one  case,  the  subsystem 
processors  retain  their  current  responsibilities,  relaying  data  back  to  the 
central  processor  which  acts  a  monitor  of  subsystem  activities.  At  the 
other  extreme,  the  central  processor  may  assume  the  responsibilities  of  the 
various  subsystem  processors,  using  the  subsystem  processors  as  intelligent 
interfaces  to  the  supported  devices.  Other  intermediate  roles  for  the 
central  processor  are  of  course  possible,  but  in  all  cases  the  subsystem 
processors  maintain  direct  interfaces  to  their  associated  devices. 
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Considerations 


The  two  connectivity  strategies  presented  above,  while  not  leading  to  a 
specific  LAN  design,  do  imply  certain  LAN  attributes. 

In  the  case  of  a  control  and  status  LAN  which  connects  all  terminal 
equipment,  such  an  approach  implies  the  need  for  network  interface  units 
suitable  for  all  equipment  types.  While  future  DSCS  equipment  may 
incorporate  the  needed  LAN  interfaces,  attachment  of  current  equipment 
would  require  the  development  of  network  interface  units.  As  in  the  full 
intercommunications  LAN,  the  network  interface  units  administer  the  lowest 
levels  of  the  OSI  Reference  Architecture.  And,  as  mentioned  in  the 
discussion  of  the  control  and  status  capabilities  of  the  full 
intercommunications  LAN,  control  and  status  signals  may  be  communicated  by 
dedicated  channels  (implying  a  reservation  access  control  protocol)  or  by 
the  techniques  of  packet-switching.  The  choice  determines  the  access 
control  protocol  implemented  by  the  network  interface  units. 

By  connecting  all  terminal  equipment  to  the  control  and  status  LAN,  the 
number  of  network  interface  units  required  is  considerably  higher  than  in 
the  second  connectivity  strategy.  Nonetheless,  if  the  terminal  central 
processor  is  to  assume  the  responsibilities  of  current  subsystem 
processors,  this  design  approach  represents  the  most  far-sighted  step 
toward  subsystem  integration. 

On  the  other  hand,  if  the  responsibility  of  interfacing  to  the  individual 
pieces  of  terminal  equipment  rests  with  the  subsystem  processors,  then  the 
control  and  status  LAN  would  support  intercommunications  between 
processors.  The  connection  of  the  subsystem  processors  to  the  local  area 
network  requires  a  network  interface  unit,  but  the  processing  power  of  the 
processors  may  be  used.  Indeed,  the  role  of  network  interface  unit  may  be 
accomplished  through  the  relatively  simple  addition  of  software  and/or 
hardware  to  the  existing  processor  systems.  Separate  network  interface 
units  would  be  necessary  for  those  devices  not  currently  supported  by  a 
subsystem  processor  yet  requiring  communications  to  the  central  processor. 
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CONTROL  AND  STATUS  LAN:  CONSIDERATIONS 


•  INTERCOMMUNICATION  OF  CONTROL  AND  STATUS  DATA  FROM  ALL  TERMINAL 
EQUIPMENT 

-  REQUIRES  NETWORK  INTERFACE  UNITS  SUITABLE  FOR  ALL  EQUIPMENT 
TYPES 

~  DEVELOPMENT  AND  DEPLOYMENT  COSTS 
—  RACK  SPACE 

-  FUTURE  SUBSYSTEMS  AND  EQUIPMENT  MAY  INCORPORATE  NEEDED  LAN 
INTERFACE  AND  CONTROL/STATUS  CAPABILITIES 

-  DEPENDING  ON  CENTRAL  PROCESSOR  ROLE,  THIS  MAY  BE  THE  MOST 
FAR-SIGHTED  DESIGN  APPROACH 

•  INTERCOMMUNICATION  BETWEEN  CENTRAL  PROCESSOR  AND  SUBSYSTEM 
PROCESSORS  ONLY 

-  PEER-TO-PEER  COMMUNICATIONS  BETWEEN  PROCESSORS  ALLOWS  USE  OF 
OFF-THE-SHELF  LAN  TECHNOLOGY 

-  SUBSYSTEM  PROCESSORS  MAY  REQUIRE  ADDITIONAL  SOFTWARE  AND 
INTERFACE  BOARDS  OR  SEPARATE  NETWORK  INTERFACE  UNITS  FOR 
EQUIPMENT  WITHOUT  CURRENT  CONTROLLER/MONITOR 

-  ROLE  OF  CENTRAL  PROCESSOR  WILL  DETERMINE  EXTENT  OF  SOFTWARE 
CHANGES  TO  SUBSYSTEM  PROCESSORS 

-  SUBSYSTEM  PROCESSORS  PROVIDE  EQUIPMENT  INTERFACES 


REPRESENTS  EVOLUTIONARY  EXTENSION  OF  EXISTING  CONTROL/STATUS 
COMMUNICATION  CAPABILITIES 
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This  use  of  subsystem  processors  represents  an  evolutionary  approach  to  the 
integration  of  terminal  subsystems,  allowing  the  central  processor  to 
assume  a  range  of  responsibilities.  Furthermore,  by  delegating  the  problem 
of  interfacing  to  particular  equipment  units  to  the  various  subsystem 
processors,  the  control  and  status  LAN  implementation  is  simplified, 
allowing  use  of  off-the-shelf  technology.  Almost  any  of  the  available 
local  area  network  options  would  be  appropriate,  the  choice  depending  on  a 
more  detailed  understanding  of  the  future  subsystem  and  central  processor 
functions  than  is  currently  available. 

Classified/Unclassified  Data 


As  discussed  in  regard  to  the  full  intercommunications  LAN,  DSCS  network 
configuration  data  is  classified  and  requires  special  treatment.  While  the 
communication  of  individual  control  and  status  information  between 
equipment  units  and  processors  as  discussed  here  is  unclassified,  the 
central  and  subsystem  processors,  however,  do  handle  classified 
information.  The  processors  themselves  may  be  split  into  red  and  black 
entities,  the  black  processors  tied  to  the  control  and  status  LAN,  or, 
alternatively.  Line  Guardian  Units  may  be  introduced  to  insure  that  all 
information  on  the  local  area  network  is  unclassified. 

The  local  area  network  may  be  required,  however,  to  support  the 
communication  of  classified  data,  one  possibility  being  the  support  of 
communications  between  the  earth  terminal  processors  and  DOSS,  the  DSCS 
Operations  Support  System.  To  fulfill  security  requirements,  either  two 
separate  local  area  networks  are  needed  or  a  single  local  area  network 
composed  of  two  distinct  physical  segments  with  the  interconnection 
protected  by  a  Line  Guardian  Unit  is  required.  The  actual  design  again 
depends  on  the  signal  flows  and  connectivities  to  be  supported  by  the  local 
area  network. 
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Observations 


From  the  above  discussion,  it  is  clear  that  a  control  and  status  local  area 
network  for  the  OSCS  earth  terminals  is  feasible.  The  specific  design  and 
implementation  of  such  a  local  area  network,  however,  depends  on  the 
connectivity  and  signal  flows  which  must  be  supported.  Two  design 
approaches  have  been  identified,  each  reflecting  different  roles  for  the 
terminal’s  control  and  status  monitor  processors.  If  the  control  and 
status  LAN  is  restricted  to  the  support  of  mostly  processor-to-processor 
communications,  the  number  of  LAN  connections  is  then  significantly  few  and 
the  cost  of  the  LAN  itself  becomes  minimal.  If,  on  the  other  hand,  all 
terminal  equipment  is  to  be  connected  to  the  control  and  status  LAN,  then 
the  cost  of  the  NIU's  per  terminal  approaches  much  higher  levels.  In 
general,  however,  the  intercommunication  of  control  and  status  signals  is 
consistent  with  the  type  of  communications  currently  supported  by  local 
area  networks,  implying  that  commercially  available,  cost-effective  LAN 
options  may  be  employed. 
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SECTION  6 

APPLICATION  OF  DIGITAL  SWITCHING  TECHNOLOGY 
TO  DSCS  SUBSYSTEM  INTEGRATION 


6.1  INTRODUCTION 

As  discussed  In  Section  3,  DSCS  earth  terminals  provide  the  communications 
equipment  needed  to  support  end-to-end  satellite  communications  of  user 
circuits  with  data  rates  from  75  bps  up  to  10  Mbps.  Integration  of  the 
earth  terminal  equipment  and  subsystems  involves  the  establishment  of 
communications  connectivities  between  devices  and  the  connectivities 
required  to  support  control  and  status  monitoring  of  the  terminal 
equipment.  While  the  previous  section  investigated  the  application  of 
local  area  network  technology  to  provide  these  connectivities,  an 
alternative  method  of  accomplishing  equipment  intercommunication  is  through 
the  use  of  digital  switching.  Digital  switching  capabilities  have  been 
developed  in  response  to  the  need  for  rapid  circuit  switching  under 
automatic  control,  especially  as  required  by  the  telephone  industry.  This 
section,  then,  discusses  the  application  of  digital  switching  technology  to 
the  DSCS  earth  terminal  integration  problem. 

The  general  digital  switching  concept  as  applied  to  DSCS  earth  terminals  is 
illustrated  in  Figure  6-1.  In  addition  to  the  three  earth  terminal 
equipment  groups  and  the  equipment  control  and  monitoring  capability,  an 
electronic  patching  function  between  each  group  of  equipment  allows  any  of 
the  outputs  of  one  equipment  group  to  be  routed,  via  central  control,  to 
any  of  the  inputs  of  the  next  group  of  equipment.  Although  not  shown  in 
Figure  6-1  switching  among  equipment  within  the  same  group  is  also 
possible.  This  switching  capability  allows  for  any  arbitrary  equipment 
configuration  to  be  established  by  a  central  control  capability.  The 
switching  capability  described  here  can  enhance  DSCS  terminal  integration 
by  allowing  dynamic  user  circuit  switching  through  the  terminal,  dynamic 
circuit  rerouting  to  avoid  failed  equipment,  automatic  configuration  status 
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and  bookkeeping,  and  remote  control.  Several  issues  arise  from  the  use  of 
electronic  patching  in  this  way.  The  three  patches  shown  in  Figure  6-1 
will,  typically,  support  signals  of  increasing  bandwidth,  from  baseband  to 
IF.  The  patch  from  the  user  signals  must  support  user  signals  of  all 
rates;  the  patch  from  the  multiplexer  group  to  the  modem  group  must 
typically  support  higher  rate  baseband  signals  (i.e.,  multiplexed  user 
signals);  and  the  patch  between  the  modem  group  and  the  RF  group  must 
support  modulated  signals  at  IF.  In  addition,  the  electronic  patch  must 
maintain  a  high  degree  of  reliability  since  without  redundant  patches  it 
represents  a  single  point  failure  for  the  terminal. 

Given  the  OSCS  integration  requirements,  the  general  digital  switching 
concepts,  and  the  issues  related  to  digital  switching  in  DSCS  terminals, 
this  section  discusses  the  use  of  a  specific  digital  switching  system 
currently  being  developed  for  use  in  military  communication  systems:  the 
Integrated  Multiplex,  Patch,  and  Test  (IMPAT)  developed  by  Martin 
Marietta.  The  following  sections  present  a  description  and  general 
applications  of  the  IMPAT,  followed  by  a  discussion  of  IMPAT  capabilities 
in  the  OSCS  earth  terminals  and  concluding  with  the  application  of  the 
IMPAT  to  the  baseline  terminal  discussed  in  Section  3,  including  an  IMPAT 
sizing  for  the  application. 


CONRCURATION 
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6.2  IMPAT  DESCRIPTION 

The  Integrated  Multiplex,  Patch,  and  Test  is  a  modular  electronic  patch  and 
multiplexer  system  employing  microprocessor  control  and  bu’lt-in  test 
capabilities.  The  IMPAT  provides  switching  control  through  electronic 
patching,  a  wide  variety  of  configurable  multiplexer  formats,  and  high 
reliability  through  self-test  and  failover  features.  This  section 
discusses  the  IMPAT' s  support  of  DSCS  user  circuit  connectivities  and 
associated  features,  control  and  monitoring  capabilities,  some  generic 
applications,  and  finally  reliability  and  availability  issues.  Since  the 
IMPAT  design  is  flexible,  its  current  capabilities  do  not  necessarily  limit 
future  IMPAT  applications.  Both  current  and  future  IMPAT  characteristic 
data  are  provided  in  detail  in  Appendix  A. 

Communication  Characteristics 


In  supporting  communication  circuits,  the  IMPAT  comprises  multiplexer  and 
demultiplexer  cards,  electronic  patch  circuits,  user  signal  I/O  cards  (8 
channels  each),  nonvolatile  memory  units,  and  a  central  processor.  These 
modular  components  allow  any  combination  of  user  I/O  and  multiplexer  access 
to  the  electronic  patch.  IMPAT  is  modularly  configured  for  a  particular 
application,  where  the  basic  IMPAT  module  provides  96  channels  consisting 
of  one  matrix  card  and  up  to  12  user  I/O,  multiplexer  or  demultiplexer 
cards  (any  combination  of  12).  Expansion  modules  can  be  added  in  two-module 
increments — up  to  16  total — bringing  the  total  capacity  up  to  1536 
channels.  The  minimum  configuration  provides  96  channels  in  one  chassis. 
The  single  rack  configuration  provides  up  to  480  channels,  while  the 
maximum  1536  channel  configuration  requires  three  racks. 

Each  IMPAT  user  I/O  card  supports  eight  channels  of  various  programmable 
user  interfaces  including  CVSD  and  PCM  up  to  64  Kbps.  The  electronic  patch 
is  implemented  using  a  time  division  multiplexing  scheme  on  a  multiple 
channel  72  kbps  internal  data  bus.  Current  implementations  use  one  channel 
of  the  internal  bus  per  patch  channel,  thereby  limiting  the  maximum  rate  to 
72  kbps.  Future  developments  will  exploit  a  technique  employing  several 
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bus  channels  per  patch  channel,  thus  allowing  rates  of  over  1.5  Mbps.  The 
multiplexer/demultiplexer  cards  are  capable  of  emulating  a  host  of  existing 
multiplexer  formats  including  the  LRM,  FCC-  98,  and  GSC-24. 

Control  and  Status  Monitoring 

The  IMPAT  provides  three  levels  of  control  and  monitoring  capability;  front 
panel,  remote,  and  the  IMPAT  mode  telemetry  channel.  The  front  panel 
interface  comprises  a  sixteen  key  key-pad  and  alphaneumeric  display  through 
which  the  operator  can  generate  and  display  configuration  data,  display 
alarm  and  status  data,  and  perform  analog  and  digital  testing.  Similarly, 
all  front  panel  control  operations  are  executable  from  the  remote  control 
interface  (RS-232  and  RS-422;  up  to  9600  baud).  A  remote  terminal  or 
processor  interface  to  the  IMPAT  permits  printing,  data  base  generation, 
and  other  software  aids  to  expedite  IMPAT  configuration  and  performace 
monitoring.  Multiplexer  operation  with  the  IMPAT  framing  format  provides 
an  in-band  telemetry  channel  on  the  composite  signal  allowing  control  and 
monitoring  via  the  composite  channel.  The  telemetry  capability  permits 
initialization  of  tests,  monitoring  of  test  results,  and  system  status 
monitoring.  In  addition,  the  telemetry  channel  can  be  used  for  system 
reconfiguration  by  initiating  a  transfer  of  data  stored  in  the  backup 
memory  to  the  on-line  memory. 

IMPAT  Applications 

Based  on  the  above  discussion  of  IMPAT  technical  capabilities.  Figure  6-2 
illustrates  some  general  IMPAT  operational  applications.  With  user  I/O 
cards  only,  IMPAT  can  be  configured  as  an  electronic  user  patch  panel, 
where  user  signals  of  various  formats  enter  the  patch,  are  routed,  and  exit 
the  patch  in  various  user  formats.  IMPAT  configured  with  mux/demux  cards 
only  provides  a  composite  channel  rassignment  function.  This  application 
may  facilitate  network  control  by  providing  a  controllable  node  capable  of 
individual  user  circuit  reassignment  in  a  single  unit.  Of  course,  any 
combination  of  multipexer  and  user  I/O  cards  is  possible,  resulting  in  a 
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variety  of  configurations  including  the  traditional  patch  and  multiplex 
configuration.  Cascaded  multiplexing  may  also  be  accomplished  with  IMPAT  by 
wiring  a  multiplexer  output  to  the  electronic  patch  input  as  a  user  signal, 
as  long  as  the  multiplexer  output  is  compatible  with  a  user  I/O  format 
available  on  the  IMPAT.  This  type  of  configuration  can  be  envisioned  to 
establish  a  fully  controllable  configuration  of  baseband  equipment. 

Availability/Reliability 

In  addition  to  the  communication,  control,  and  status  monitoring 
capabilities,  the  IMPAT  provides  several  reliability  features.  The  fact 
that  the  IMPAT  would  consolidate  the  functions  of  various  equipment  into  a 
single  unit,  leaving  an  earth  terminal  vulnerable  to  a  single  point  failure 
in  the  IMPAT  unit,  necessitates  the  requirement  for  high  reliability  of  the 
IMPAT.  The  IMPAT  provides  diagnostics  comprising  user  interface,  framing, 
timing,  and  hardware  monitoring  and  built-in  analog  and  digital  testing. 

The  IMPAT  configuration  includes  redundant  components  and  provides  the 
capability,  under  microprocessor  control,  to  detect  failed  components  and 
switch  to  redundant  components  or  circuits.  Similarly,  the  IMPAT  can  be 
used  to  switch  from  failed  to  redundant  equipment  external  to  the  IMPAT.  A 
terminal  control  processor  is  envisioned  which  would  detect  an  equipment 
failure  and  command  the  IMPAT  to  switch  the  failed  equipment  input  to  that 
of  a  spare.  Network  availability  may  also  be  enhanced  by  the  IMPAT 's  quick 
rerouting  capability,  allowing  reconfiguration  of  a  network  to  adapt  to 
stressed  conditions.  Finally,  the  operational  configuration  data  of  the 
IMPAT  is  stored  in  its  nonvolatile  memory  where  it  can  be  used  to  restore 
the  terminal  configuration  in  the  event  of  a  disruption. 

Observations/Comparisons 

Along  with  the  information  provided  in  this  section,  it  may  be  helpful  to 
put  the  IMPAT' s  capabilities  in  perspective  by  comparing  them  to  those  of 
the  equipment  which  the  IMPAT  might  replace.  The  IMPAT' s  electronic  patch 
function  replaces  the  manual  patch  panel  in  current  terminal  configura¬ 
tions.  Although  the  IMPAT  patch  is  fully  and  remotely  controllable,  being 
an  active  device  it  is  subject  to  failure.  The  IMPAT  multiplexer  function 
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saves  a  considerable  amount  of  space  and  power  consumption  since  the 
multiplexers  are  implemented  on  cards  instead  of  an  entire  rack  chassis,  as 
is  the  case  with  existing  multiplexers. 

It  should  be  noted  that  the  IMPAT  characteristics  described  here  are  not 
all  under  the  current  IMPAT  development  contract  but  are  being  considered 
for  future  implementations.  The  IMPAT  multiplexers  can  emulate  a  variety 
of  existing  multiplexer  framing  formats;  however,  because  of  the  patch 
channel  rate  limitation,  it  does  not  always  perform  the  identical  function 
of  these  multiplexers.  For  example,  the  GSC-24  accepts  inputs  up  to  3  Mbps; 
the  current  IMPAT,  emulating  the  GSC-24,  only  accepts  inputs  up  to  64kbps. 
Details  of  the  proposed  IMPAT  capabilities  and  those  currently  under 
contract  are  provided  in  Appendix  A. 
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6.3  USE  OF  IMPAT  IN  THE  DSCS  EARTH  TERMINALS 

Based  on  the  IMPAT  capabilities  discussed  in  the  previous  section  and  the 
intercommunication  requirements  of  the  DSCS  earth  terminals,  several  uses 
of  IMPAT  to  support  DSCS  terminal  intercommunications  are  evident.  Two 
types  of  intercommunication  are  treated  separately:  support  of  the  user 
communication  circuits  and  the  consolidation  of  control  and  monitoring 
signals  within  the  earth  terminal. 

The  use  of  IMPAT  to  provide  communications  connectivities  in  support  of 
DSCS  user  signals  is  presented  through  a  discussion  of  how  IMPAT  may 
establish  the  typical  baseband  equipment  chains  of  Section  3.  Figure  6-3 
illustrates  the  implementation  of  specific  equipment  chains  using  IMPAT  by 
comparing  the  current  DSCS  configuration  with  an  equivalent  IMPAT 
configuration  approach.  Note  that  IMPAT' s  electronic  patch  function  allows 
controlled  switching  between  all  baseband  equipment,  while  its  multiplexer 
function  allows  replacement  of  the  individual  multiplexers.  This  concept 
of  baseband  equipment  chains  is  generalized  in  Figure  6-4. 

In  the  configuration  of  Figure  6-4,  all  user  signals  access  the  baseband 
equipment  via  the  IMPAT  electronic  patch.  Similarly,  all  baseband  equipment 
outputs  connect  to  other  equipment  via  the  electronic  patch.  When  a  given 
signal  is  ready  to  be  modulated  it  is  again  passed  through  the  electronic 
patch  and  then  on  to  the  modems.  This  configuration  provides  maximum 
connectivity  and  flexibility  since  the  electronic  switch  provides  the 
connection  between  each  equipment  pair.  Such  a  switching  capability  allows 
for  circuit  rerouting  within  the  terminal  in  the  event  of  an  equipment 
failure,  as  well  as  rerouting  in  the  network  (if  all  terminals  are 
appropriatly  equipped)  for  network  reconfiguration  or  for  adaption  to 
stressed  environments.  This  application  of  IMPAT  also  results  in  a 
somewhat  standarized  terminal  wiring  scheme,  since  equipment  in  every  earth 
terminal  is  connected  to  the  IMPAT  in  the  same  way.  Since  the 
configuration  of  the  IMPAT  determines  the  terminal  configuration,  unique 
configurations  can  be  implemented  through  the  IMPAT  configuration  which  may 
be  generated  via  software. 


CURRENT  DSCS  CONRCURATIONS  EQUIVALENT  IMPAT  CONFIGURATION 
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Although  the  concept  of  IMPAT  establishing  baseband  equipment  chains 
appears  beneficial,  several  requirements  must  be  imposed  on  the  IMPAT  to 
realize  the  concept.  The  IMPAT  must  support,  via  user  interfaces,  the 
transmission  of  the  highest  data  rate  signal  in  the  terminal,  which  may  be 
on  the  order  of  6  Mbps.  The  IMPAT  configuration  currently  under  contract, 
however,  cannot  accept  inputs  greater  than  64  kbps.  As  noted  in  the 
previous  subsection,  the  ability  to  support  higher  data  rates  is  expected 
to  be  available  in  future  versions  of  IMPAT. 

The  second  type  of  connectivity  which  must  be  provided  for  earth  terminal 
integration  is  that  which  supports  the  communication  of  control  and  status 
monitoring  information  between  earth  terminal  devices  and  a  central 
controller/monitor.  The  configuration  of  Figure  6-5  suggests  the  concept 
of  IMPAT  providing  a  centralization  of  equipment  control  and  status 
monitoring  signals.  Equipment  control  and  status  monitoring  interfaces  are 
routed  through  the  electronic  patch  to  a  multiplexer  which  interfaces 
directly  with  the  controller/monitor  processor.  The  IMPAT  in  this 
application  would  additionally  provide  the  ability  to  switch  control  from  a 
failed  control /monitor  processor  to  a  redundant  processor. 

In  order  for  IMPAT  to  provide  the  control  and  status  monitoring  capability 
described  above,  it  must  have  user  I/O  interfaces  compatible  with  the 
equipment  control  and  monitor  interfaces.  The  IMPAT  must  also  provide  a 
multiplexing  format  which  is  amenable  both  to  the  equipment  signals  and  the 
central  processor  interface. 


EQUIPMENT  A 
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6.4  USE  OF  IMPAT  IN  BASELINE  DSCS  EARTH  TERMINALS 

The  previous  section  discussed  various  ways  in  which  the  IMPAT  may  support 
the  user  communication  and  control  and  status  monitoring  connectivities 
required  for  DSCS  earth  terminal  integration.  To  provide  a  concrete 
example  of  integration  using  IMPAT  and  a  basis  for  sizing,  this  section 
presents  the  application  of  IMPAT  to  the  baseline  terminals  discussed  in 
Section  3.  Two  configurations  are  presented  with  an  IMPAT  sizing  for 
each.  The  first  example  reflects  the  use  of  IMPAT  beyond  its  current 
capabilities,  employing  the  IMPAT  architecture  to  the  fullest.  The  second 
example  provides  a  configuration  which  reflects  only  the  IMPAT  capabilities 
which  are  currently  under  contract  to  be  provided  by  Martin  Marietta.  The 
following  discusses  the  sizing  methodology  for  the  case  of  a  baseline  light 
DSCS  earth  terminal. 

The  first  configuration  of  Figure  6-6  is  a  specific  example  of  IMPAT 
establishing  baseband  equipment  chains  as  in  the  generic  configuration  of 
Figure  6-4,  All  signals  entering  the  patch  are  routed  either  to  one  of  the 
IMPAT  multiplexers  or  directly  out  to  the  modems  through  user  I/O. 
Multiplexer  outputs  are  fed  back  to  IMPAT  user  I/O  interfaces.  Of  course, 
this  configuration  assumes  that  the  IMPAT  is  capable  of  accepting 
multiplexer  outputs  and  high  rate  user  signals  as  inputs  through  the  user 
I/O  cards.  The  modem  and  RF  equipment  configuration  is  unchanged  from  the 
baseline  terminal  of  Section  3. 

To  estimate  the  size  of  the  IMPAT  needed  to  fullfill  the  requirements  for 
communication  in  this  terminal,  the  number  of  multiplexer  cards, 
demultiplexer  cards,  user  I/O  ports,  and  patch  channels  must  be 
calculated.  Since  the  circuits  are  assumed  to  be  full  duplex,  a 
multiplexer  and  demultiplexer  card  is  required  for  each  multiplexer  in 
Figure  6-6.  Each  multiplexer  output  feeds  back  to  a  user  I/O  port,  each 
modem  connects  to  an  I/O  port,  and  each  user  circuit  connects  to  an  I/O 
port.  The  total  number  of  multiplexer,  demultiplexer,  and  user  I/O  (8 
ports  each)  including  1  for  4  redundancy  determines  the  number  of  IMPAT 

/I 


FIGURE  6-6:  NETWORK  TERMINAL  CONFIGURATION  WITH  IMPAT 
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modules  required  (12  cards  per  module).  In  addition,  each  IMPAT  module 
provides  96  patch  channels — if  this  does  not  meet  the  maximum  number  of 
interfaces  on  one  side  of  the  patch,  additional  modules  are  required.  The 
mininum  IMPAT  configuration  contains  one  module,  a  single  rack  contains 
three  to  five  modules,  and  additional  racks  may  contain  up  to  six  modules 
where  the  maximum  is  16.  Table  6-1  presents  the  sizing  for  the 
configuration  of  Figure  6-6. 

The  second  IMPAT  configuration  illustrated  in  Figure  6-7  involves  only  the 
current  capabilities  of  IMPAT.  Signals  entering  the  electronic  patch  of 
the  IMPAT  are  restricted  to  64  kbps  or  less,  and  multiplexer  outputs  are 
not  fed  back  into  the  IMPAT  user  I/O  ports.  In  this  configuration  the 
IMPAT  provides  an  electronic  patch  only  for  those  users  less  than  64  kbps 
and  replaces  only  the  first  stage  of  multiplexers.  The  second  stage  of 
multiplexers  must  be  provided  externally. 

The  IMPAT  sizing  for  this  configuration  is  similar  to  the  previous  sizing 
with  the  following  modification.  The  multiplexer  cards  needed  are  twice 
the  number  of  first  stage  multiplexers,  and  the  user  I/O  ports  required  is 
equal  to  the  number  of  user  signals  with  rates  less  than  64  kbps.  Table  6-2 
shows  the  calculated  sizing  for  the  configuration  of  Figure  6-7. 

The  sizing  methodology  explained  above  was  used  along  with  the  data 
provided  in  Tables  3-1  and  3-2  to  estimate  the  IMPAT  requirements, 
reflecting  current  and  extended  IMPAT  capabilities,  for  the  medium  and 
heavy  terminals  as  well  as  the  light.  The  results  are  summarized  in 
Table  6-3. 


RGURE  6-7:  NETWORK  7IRMINAL  CONRGURAnON  WITH  IMPAT  (CURRENT  CAPABIUTY) 

1RS5015e\M00391 
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TABLE  6-1 

IMPAT  SIZING  (EXTENDED  CAPABILITY) 


HUX  CARDS 

8  MUX  10  MUX 

1  FOR  4  REDUNDANCY 

8  DEMUX  10  DEMUX 

20  CARDS  TOTAL 


USER  I/O  CAROS 


8  PORTS  FOR  MUX  OUTPUT 
69  PORTS  FOR  USER  INPUT 
_8_P0RTS  FOR  OUTPUT  TO  MODEM 
85  TOTAL  PORTS 

8  PORTS/CARD  Z^>  11  CARDS 

1  FOR  4  REDUNDANCY  14  CARDS 

PATCH  CHANNELS 


USERS  INPUT  69 
INPUT  FROM  MUX  OUTPUT  _B 
TOTAL  REQUIRED  CHANNELS  77 

REQUIRED  IMPAT  CONFIGURATION 


10  MUX 
10  DEMUX 
14  I/O 

34  CARDS  12  CARDS  PER  MOOMLE  z^  3  MODULES 

3  MODULES  PROVIDES  288  CHANNELS 


1  IMPAT  BASIC  MODULE  WITH  A  2  MODULE  ADDITION  FITS  IN  ONE  RACK  WITH  ROOM 
FOR  2  MORE  MODULES. 
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TABLE  6-2 

IMPAT  SIZING  (CURRENT  CAPABILITY) 
MUTLIPLEXER  CAROS 

7  HUX 

7  DEHUX 


USER  I/O  CAROS 

69  PORTS  FOR  USER  INPUT 

8  PORTS  PER  CARO  9  CARDS 

1  FOR  4  REDUNDANCY  11  CARDS 


PATCH  CHANNELS 

USER  INPUTS  69 

REQUIRED  INPAT  CONFIGURATION 

9  MUX 
9  DEMUX 
11  I/O 

29  CARDS  12  CAROS  PER  MODULE  3  MODULES 


3  MODULES  PROVIDES  288  CHANNELS 

SINGLE  RACK  3  MODULE  CONFIGURATION;  ALLOWS  ROOM  IN  RACK  FOR  2  ADDITIONAL 
MODULES. 


IHPAT  CONFIGURATION 
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IMPAT 

COMPONENTS 


MULTIPLEXER 

CARDS  REQUIRED 


MULTIPLEXER 

CARDS  REDUNDANT 


USER  I/O  CARDS 
REQUIRED 


USER  I/O  CAROS 
REDUNDANT 


PATCH  CHANNEL 

REQUIREMENTS 


MUX  CARDS 


DEMUX  CAROS 


USER  I/O  CARDS 


CHANNELS 

AVAILABLE 


#IMPAT 

MODULES 


fIMPAT 

RACKS 


BASELINE  TERMINALS 

LIGHT 

6.24  MBPS 

MEDIUM 

12.41  MBPS 

HEAVY 

37.46  MBPS 

14/16 

46/60 

40/66 

4/4 

12/16 

10/18 

9/11 

36/43 

48/61 

2/3 

9/11 

12/16 

69/77 

281/319 

381/423 

9/10 

29/38 

20/42 

9/10 

29/38 

20/42 

11/14 

45/54 

60/77 

288/288 

864/1152 

864/1344 

3/3 

9/12 

9/14 

1/1 

2/3 

2/3 
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APPENDIX  A 

DCSS  EQUIPMENT  DOCUMENTATION 

This  appendix  contains  a  list  of  equipment  employed  in  the  Digital 
Communications  Subsystem  (DCSS)  of  the  DSCS  earth  terminals.  Based  on 
available  documentation  associated  with  the  equipment,  information  is 
compiled  here  which  pertains  to  the  communication,  status  and  control 
information  transfer  among  the  equipment  in  an  earth  terminal.  The 
communication,  control,  and  status  connectivities  as  well  as  interfaces  are 
provided  to  the  extent  that  information  was  available  for  each  set  of 
equipment. 
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A-1  AN/USC-28  MODEM 

Advanced  spread  spectrum  satellite  communications  modulator/demodulator. 
Used  in  DSCS  terminals  for  the  modulation  and  demodulation  of  ECCM  user 
circuits.  Operation  in:  spread  spectrum  AJ  and  mitigation  modes,  TOMA  or 
TDM  modes,  voice  and  graphics  modes.  Also  provides  ECCM  network  infor¬ 
mation  from  all  NT's  to  the  USC-28  at  the  NCT  which  interfaces  to  the  ECCM 
Controller  computer  to  provide  centralized  network  control  of  the  ECCM 
network.  Each  modem  consists  of  a  central  controller  and  up  to  15 

receive/transmit  (R/T)  units. 

Connectivities: 

•  Communications: 

-  Inputs: 

—  AJ  critical  control  circuit  teletype  orderwire 
—  Up  to  15  AJ  digital  data  channels  75  bps  to  2.5  Mbps 
—  One  75  bps  orderwire  for  each  digital  channel 
—  Interface  to  KY-801  codec  75  bps  to  2.5  Mbps 
—  Interface  with  KY-883  codec  75  bps  to  100  Kbps. 

-  Outputs: 

—  70MHz  or  700MH2  interface  to  SHF  terminal, 
a  Control  and  Status: 

-  Status  Monitoring  if  output  to  a  display  terminal  associated 
with  the  modem 

-  Control  and  status  information  is  passed  through  the  network 
(via  CCC)  to  the  NCT  from  all  USE-28  modems  in  the  network. 


Interfaces: 

•  Control  and  Status: 

-  USC-28  interfaces  to  ECCM  control  computer  via  IEEE  488  GPIB 
port  at  2400  baud. 
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A-2  MD-XXXOODEM 

Non-ECCM  offset  QPSK/BPSK  modem  with  forward  error  correcting  coding/ 
decoding.  For  modulation  of  non-ECCM  user  signals.  Operates  in  the 
following  modes:  BPSK  with  now  FEC  coding,  BPSK  with  rate  1/2  or  3/4  FEC 
coding,  OQPSK  with  no  coding,  OQPSK  with  rate  1/2  or  3/4  FEC  coding.  Each 
modem  set  consists  of  a  master  controller  module  and  several  receiver  and 
transmitter  modules  (up  to  sixteen  total  per  control  module).  The  minimum 
configuration  is  one  receiver  module,  one  transmitter  module  and  one 
control  module. 

Connectivities: 

•  Communications: 

-  Inputs: 

—  Clock  and  data  input  for  each  receive/transmit  module. 


BPSK 

OQPSK 

no  coding  16kbps  to 

10  Mbps 

20  Mbps 

rate  1/2  16kbps  to 

5  Mbps 

10  Mbps 

rate  3/4  16kbps  to 

7.5  Mbps 

15  Mbps 

—  Compatible  with  AN/FCC-98,  AN/GSC-24,  MD-1002/G,  MD- 
920  /G,  LRM,  KY-801,  KG-81  and  others. 

-  Outputs; 

—  70MHz  CW,  OQPSK,  or  BPSK  with  filtering. 

•  Control  and  Status; 

-  For  each  set  control  and  status  for  each  of  the  transmit 
receive  modules  is  handled  through  the  control  module 

-  Each  receive  module  has  an  interface  to  the  ALPC.  (soft 
decision,  timing,  and  Es/No) 

-  Each  control  module  has  an  interface  to  a  remote  controller. 
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Interfaces: 


Communications: 

-  Data  and  clocks  —  Bendix  34105-1  connector 

-  IF  —  TNC-type  connector. 

Control  and  Status: 

-  ALPC  interface  —  RS-449 

-  Remote  Control  —  RS-449. 
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A-3  INTEGRATED  MULTIPLEX  PATCH  AND  TEST  (IMPAT) 

IMPAT  functionally  replaces  a  digital  matrix  switch  followed  by  a  set  of 
multiplexers.  The  equipment  includes  a  controllable  electronic  patch, 
programmable  multiplexers,  a  control  processor,  self  testing  facilities  and 
an  operator  interface.  IMPAT  accepts  and  outputs  user  signals  in  digital, 
analog  to  PCM,  analog  to  CVSD,  and  FSK  to  digital  compatible  with  TRI-TAC, 
GSC-24,  TD-1069,  TD-660,  T1  (FCC-98),  and  NATO.  The  IMPAT  currently  under 
contract  to  Martin  Marietta  has  limited  capabilities;  the  design,  however 
is  flexible  and  capability  upgrades  are  expected.  The  data  below  reflects 
Martin  Mariettta's  expectations  of  the  ultimate  IMPAT  implementation.  A 
second  set  of  data  applies  to  the  version  of  IMPAT  which  is  currently  being 
developed  under  contract. 


Ultimate  IMPAT  Configuration 


Connectivities: 


•  Communications: 

-  User  signals  (user  I/O  ports): 

—  Analog  to  PCM  48  /  64  kbps 
—  Analog  CVSD  16  /  64  kbps 
—  Digital  up  to  1.5  Mbps  (future) 

—  96  patch  channels  per  module,  can  be  increased  to  96  x 
16  in  increments  of  96  composite  signals  (multiplexer 
outputs): 

-  Composite  Signals  (Multiplexer  Outputs): 

—  Up  to  3  Mbps  (future). 

•  Status  and  Control: 

-  Controlled  by  central  processor  and  operator  terminal 

-  Remote  control  for  all  front  panel  operations 

-  Audio  and  visual  alarms 

-  Telemetry  channel  for  remote  configuration  status  and  test 
via  the  composite  channel. 
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Interfaces: 


t  Communications: 


-  Compatible  with  TD-754,  KG-27,  KG-81,  KG-84 


•  Control  and  Status: 

-  Remote  control  via  serial  RS-449  interface  operating  at  110 
to  9600  bps 


-  Remote  alarms  via  separate  connector  (relay  type  alarms). 
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IMPAT  Configuration  Under  Contract 

•  _ hardware  Configuration: 

-  Single  rack 

-  3  multiplexer;  3  demultiplexer  cards 

-  8  digital  user  I/O  cards 

-  2  CVSD  user  I/O  cards 

-  3  switch  matrix  cards 

-  2  nonvolatile  memory  cards 

-  1  microprocessor  card. 

•  Multiplexer  Emulation: 

-  FCC-98 

-  GSC-24  (inputs  less  than  64  kbps;  15  channels;  aggregate  up 
to  1  Mbps) 

-  TD-1235 

-  TD-660 

-  TO- 1069 

-  NATO  30  channel  PCM  format. 
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A-4  AN/FCC-98  MULTIPLEXER 

MuUiplexer/Oemultiplexer  performs  analog  to  digital  conversion  (PCM)  of  up 
to  24  (4  kHz)  voice  channels  and  time  division  multiplexing  to  form  the 
aggregate  channel.  Voice  channel  cards  can  be  replaced  by  50  kbps  data 
cards.  This  multiplexer  typically  precedes  a  GSC-24(v)  multiplexer. 

Connectivities; 

•  Communications: 

-  User  signals; 

—  24  voice  or  data  channels  up  to  64kbps  per  channel 

-  Composite  signals: 

—  Compatible  with  following  equipment; 

Rates  (kb/s) 

KG-81  192,  384,  768,  1544 

AN/GSC-24  192,  384,  768,  1544 

VICOM  4000-02  1544 

•  Status  and  Control; 

-  Audio-visual  alarms,  remote  and  front  panel 

-  Control  from  front  panel  only. 


Interfaces; 


t  Communications: 

-  Voice  channel  input  ful  duplex  4  wire 

-  Full  duplex  data  channels. 


•  Control  and  Status: 

-  Remote  alarms  use  relay  switches. 
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A-5  LOW  RATE  MULTIPLEXER  (LRM) 

Low  rate  adaptive  time  division  multiplexer/demultiplexer.  Up  to  twelve 
duplex  channels  of  digital,  FSK,  or  voice  frequency  (CVSD  conversion)  at 
rates  up  to  56  Kbps  per  channel  with  a  maximum  aggregate  rate  of 
256  Kbps.  The  LRM  is  replacing  the  GSC-24  in  equipment  chains  supporting 
ECCM  circuits. 

Connectivities: 

•  Communications: 

-  Demultiplexed  signals: 

—  12  duplex  channels;  digital,  FSK  VF  (CVSD) 

—  Up  to  56  kbps 

—  Any  combination  of  rates  and  types 

—  8  channels  all  at  16  or  32  kbps  for  Loop  Group  Modem 
(LGM)  mode. 

-  Composite  signals: 

—  Maximum  rate  25kbps 

—  Compatible  with  LGM,  AN/GSC-24  and  others 

—  128  or  256  kbps  for  LGM  mode. 

•  Status  and  Control: 

-  Remote  control 

-  Additional  demultiplexed  channel  for  control. 


Interfaces: 

•  Control  and  Status: 

-  Remote  control  interface;  150  -  9600  baud;  RS-499 

-  Interfaces  with  DECS  remote  processor  via  remote  control. 
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A-6  LOW  SPEED  TIME  DIVISION  MULTIPLEXER  (LSTDM) 

Low  speed  TDM  accepts  as  input  and  provides  as  output  NRZ  or  conditioned 
diphase  signals.  Typically  used  in  the  link  between  the  Technical  Control 
Facility  and  the  Earth  Terminal. 

Connectivities: 

f  Communications: 

-  Demultiplexed  signals: 

—  16  ports  of  35  to  32  kbps 

—  Synchronous,  isochronous  or  asynchronous 
—  Mode  changed  via  modular  card  replacement. 

-  Multiplexed  signals: 

—  Rates  (including  overhead)  of  1.2  to  256  kbps 
—  Synchronous,  isochronous  or  asynchronous. 

•  Status  and  Control : 

-  Remote  alarms  (  audio  and  visual  type). 
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A-7  AN/GSC-24  MULTIPLEXER 

Multiplexer/Demultiplexer  accepts  high  rate  digital  signals,  performs  time 
division  multiplexing,  and  outputs  the  resulting  high  rate  digital  signal. 
This  multiplexer  typically  accepts  Inputs  from  the  FCC-98  multiplexer  and 
high  rate  users  (>  100  Kbps).  Its  is  being  replaced  in  ECCM  circuits  by 
the  Low  Rate  Multiplexer. 

Connectivities: 

•  Communications: 

-  User  Signals: 

—  24  data  channels  50  bps  to  3  Mbps 

-  Composite  signals: 

—  Less  than  10  Mbps. 

•  Status  and  Control: 

-  Front  panel  access  only 

-  Reconfiguration  requires  rewiring. 
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APPENDIX  B 

COMMERCIAL  LAN  PRODUCTS 

The  tables  provided  1n  this  appendix  list  by  vendor  the  various  local  area 
network  products  currently  conwnercidlly  available.  While  the  information 
in  the  tables  does  not  suffice  to  provide  full  descriptions  of  the 
products,  it  does  serve  to  illustrate  the  variety  of  products  on  the 
market.  As  can  be  seen,  many  vendors  provide  a  range  of  products  with 
different  capabilities,  although  none  provides  a  product  suitable  for  use 
as  the  DSCS  terminal  full  intercommunications  LAN.  Depending  on  the  design 
strategy  employed,  however,  any  number  of  the  products  indicated  here  might 
be  suitable  for  use  as  the  DSCS  terminal  control  and  status  LAN. 

The  list  is  somewhat  dated,  having  been  compiled  from  information  dating 
from  mid-1985 — since  that  time,  IBM  has  announced  its  token-ring  LAN, 
FiberLAN  (formerly  Siecor  FiberLAN)  has  introduced  its  fiber-optic  TDM 
ring,  and  other  products  have  entered  the  market.  The  products  listed 
here,  however,  are  still  currently  available  and  represent  the  various 
forms  in  which  possible  LAN  alternatives  are  being  made  commercially 
available. 
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Data  rate  Max.  Max.  Interface 

CtMfiany/Product  Naae  Media  Access  Technique  (bps)  stations  distance  ports 


Data  rate  Max.  Max.  Interface 

Coapany/Product  Naae  Media  Access  Technique  (bps)  stations  distance  ports 


parallel 
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APPENDIX  C 

THROUGHPUT  REQUIREMENTS  FOR 
A  FULL  INTERCOMMUNICATIONS  LAN 

The  objective  of  this  appendix  is  to  produce  a  reasonable  estimate  of  the 
requirements  of  the  full  intercommunications  local  area  network  suggested 
in  Section  5  of  this  report  to  support  subsystem  integration  in  the 
baseline  light,  medium,  and  heavy  terminals.  The  information  required  to 
make  such  an  estimate  consists  of  the  number  of  users  and  associated  data 
rates,  the  number  of  each  equipment  type,  and  the  number  of  equipment-to- 
equipment  connectivities  and  the  associated  data  rates.  Based  on  this 
information  the  number  of  Network  Interface  Units  (NIU)  and  the  cable 
bandwidth  requirements  can  be  assessed.  Similarly,  the  information 
compiled  here  can  also  be  used  to  estimate  a  sizing  of  IMPAT  capabilities 
required  to  support  equipment  to  equipment  interconnections  in  the  baseline 
terminals. 

Information  gathered  here  pertains  to  typical  light,  medium,  and  heavy 
terminals.  The  MIST  is  used  as  the  baseline  light  terminal  with  the  MIST 
specification  as  the  source  of  information;  the  medium  and  heavy  terminals 
are  based  on  two  representative  DSCS  terminals  with  information  originating 
from  the  DSCS  Program  Plan.  The  MIST  Specification  provides  all  necessary 
information  while  the  DSCS  Program  Plan  provides  ECCM  and  FOMA  user 
information;  however,  equipment  information  is  provided  only  for  the  ECCM 
circuits  and  multiplexer  plans  are  not  included.  The  DSCS  Transition  and 
Implementation  Plan  (TIP),  though,  does  provide  FOMA  equipment  information 
and  multiplexer  plans  for  some  of  the  links.  Since  the  Program  Plan  and 
TIP  reflect  implementation  plans  devised  at  different  points  in  time,  their 
information  is  inconsistent  and  therefore  cannot  be  readily  used  in 
combination.  Because  of  the  incomplete  and  contradictory  information 
available,  the  number  of  FOMA  equipment  and  multiplexing  plans  are 
estimated  with  the  available  information  as  a  basis.  The  user  information 
provided  in  Table  3-1  along  with  ECCM  equipment  information  is 
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TERMINAL  SIZING  ESTIMATION 


•  INFORMATION  REGARDING  DSCS  TERMINAL  EQUIPMENT  AND  USERS  PRESENTED  IN 
DSCS  PROGRAM  PLAN  AND  TRANSITION  IMPLEMENTATION  PLAN  (TIP)  IS 
CONTRADICTORY  AND  INCOMPLETE 

•  USER  SIGNAL  INFORMATION  HAS  BEEN  OBTAINED  FROM  THE  PROGRAM  PLAN 

•  ECCM  EQUIPMENT  INFORMATION  HAS  BEEN  OBTAINED  FROM  THE  PROGRAM  PLAN 

•  FDMA  EQUIPMENT  INFORMATION  HAS  BEEN  OBTAINED  FROM  THE  TIP»  SCALED  AND 
APPLIED  TO  THE  PROGRAM  PLAN  USER  DATA 

-  MODEM  SCALE  FACTOR  REFLECTS  TERMINAL  AGGREGATE  DATA  RATE 

-  MULTIPLEXER  SCALE  FACTOR  REFLECTS  NUMBER  OF  USER  SIGNALS 

•  MULTIPLEXER  PLANS  CONSTRUCTED  BASED  ON  SCALED  EQUIPMENT  AND  USER 
SIGNAL  INFORMATION  ASSOCIATED  WITH  THE  BASELINE  TERMINALS 

•  MULTIPLEXER  PLANS  PROVIDE: 

-  EQUIPMENT-TO-EQUIPMENT  CONNECTIVITY  AND  ASSOCIATED  DATA  RATES 

-  NUMBER  OF  EACH  EQUIPMENT  REQUIRED 
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extracted  from  the  Program  Plan  and  used  as  the  basis  for  sizing  the 
baseline  terminals. 

The  information  regarding  equipment  and  multiplexer  plans  found  in  the  TIP 
has  been  scaled  based  on  the  parameters  which  drive  the  number  of  equipment 
used  in  the  terminals.  The  number  of  FDMA  equipment  found  in  the  TIP 
applies  to  the  number  of  users  and  aggregate  data  rate  as  described  in  the 
TIP  for  the  given  terminal.  Since  the  aggregate  data  rate  which  must  be 
supported  by  a  terminal  influences  the  number  of  modems  employed,  the  scale 
factor  used  for  the  modems  and  associated  equipment  is  the  ratio  of  the 
total  baseline  terminal  FDMA  rate  to  the  total  FDMA  rate  of  the  terminal 
detailed  in  the  TIP.  Similarly,  the  number  of  user  signals  determines  the 
number  of  multiplexers  required.  Therefore,  the  scale  factor  for 
multiplexers  is  the  ratio  of  the  baseline  terminal  FDMA  users  to  the  FDMA 
users  of  the  terminal  presented  in  the  TIP. 

Based  on  the  multiplexer  plans  found  in  the  TIP,  representative  multiplexer 
plans  are  constructed  for  each  of  the  baseline  terminals  using  the  scaled 
numbers  of  equipment  in  the  TIP  for  FDMA  circuits,  the  Program  Plan  data 
for  ECCM  circuits,  and  the  user  signal  information  in  Table  3-1.  From 
these  constructions  the  equipment-to-equipment  connections  and  associated 
data  rates  are  computed  and  presented  in  Tables  C-1,  C-2,  and  C-3  for  the 
light,  medium,  and  heavy  baseline  terminals,  respectively.  The  LAN  must 
provide  a  variety  of  services  in  terms  of  data  rate  and,  as  a  result,  the 
demand  for  each  service  must  be  assessed.  The  tables  break  up  the  number 
of  connections,  for  each  connection  type,  by  data  rate  into  representative 
services  to  show  the  number  of  connections  requiring  each  service.  For 
example,  in  the  light  terminal  (Figure  C-1),  3  connections  require  a 
service  providing  at  least  64  Kbps. 

The  implementation  of  the  full  intercommunications  LAN  of  Section  5 
requires  a  Network  Interface  Unit  (NIU)  for  each  piece  of  equipment  in  the 
terminal.  Since  the  complexity  and  cost  of  each  of  these  NIU's  depends  on 
the  number  of  connections  to  the  LAN  the  associated  equipment  requirzs,  a 
representative  equipment  listing  including  the  number  of  connections  to  the 
LAN  per  device  for  the  light,  medium,  and  heavy  baseline  terminals  is 
presented  in  Table  C-4.  End  device  in  the  terminal  performs  an  operation 
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TABLE  C-2 

REPRESENTATIVE  MEDIUM  TERMINAL  CONNECTIVITIES  AND  RATES 


NUMBER  OF  CONNECTIONS 

CONNECTION  TYPE 

1  Kbps 

64  Kbps 

500  Kbps 

1  Mbps 

2  Mbps 

8  Mbps 

TOTAL 

FCC-98 

/  GSC-24 

k 

4 

3 

1 

3 

11 

2  § 

l.B 

Kbps 

1  9 

5.85 

Kbps 

1  9 

52.8 

Kbps 

1  9 

350 

Kbps 

2  9 

128 

Kbps 

1  9 

832 

Kbps 

1  9 

1408 

Kbps 

2  9 

1544 

Kbps 

GSC-24 

/  R/T* 

2 

1 

2 

1 

6 

1  9 

1.8 

Kbps 

1  9 

7.65 

Kbps 

1  9 

180.8 

Kbps 

1  9 

1182 

Kbps 

1  9 

1536 

Kbps 

1  9 

3088 

Kbps 

LRM  /  R/T 

6 

2 

1 

9 

1  9 

121.6 

Kbps 

1  9 

13.2 

Kbps 

1  9 

3.45 

Kbps 

1  9 

.825 

Kbps 

5  9 

.9 

Kbps 

KG-84  / 

LRM 

2 

2  9 

2.4 

Kbps 

TOTAL 

6 

10 

5 

1 

5 

1 

26 

*  NUMBER  OF  EQUIPMENT  SCALED  FROM  NUMBER  IN  TIP. 
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TABLE  C-3 

REPRESENTATIVE  HEAVY  TERMINAL  CONNECTIVITIES  AND  RATES 


NUMBER  OF  CONNECTIONS 

CONNECTION  TYPE 

1  Kbps 

64  Kbps 

500  Kbps 

1  Mbps 

2  Mbps 

FCC-98 

/  GSC-24 

5 

2 

2 

5 

1  9 

1.5 

Kbps 

1  9 

1.725 

Kbps 

1  9 

1.8 

Kbps 

1  9 

24 

Kbps 

1  9 

51 

Kbps 

1  9 

88.8 

Kbps 

1  9 

401.6 

Kbps 

1  9 

808 

Kbps 

1  9 

960 

Kbps 

1  9 

1200 

Kbps 

4  9 

1544 

Kbps 

GSC-24 

/  R/T  (MD-1007) 

1 

4 

1 

3 

1  9 

1.725 

Kbps 

1  9 

344.8 

Kbps 

1  9 

307 

Kbps 

1  9 

280 

Kbps 

1  9 

769.5 

Kbps 

1  9 

1000 

Kbps 

1  9 

1704 

Kbps 

1  9 

1602 

Kbps 

1  9 

1538 

Kbps 

1  9 

3304 

Kbps 

1  9 

2888 

Kbps 

LRM/  R/T  (USC-28) 

1 

3 

1  9 

.75 

Kbps 

1  9 

7.8 

Kbps 

1  9 

5.77 

Kbps 

1  9 

28.8 

Kbps 

KG-84/ 

RA  (use- 

-28) 

5 

5  9 

2.4 

Kbps 

TOTAL 

1 

14 

6 

3 

8 
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TABLE  C-4 


REPRESENTATIVE  EQUIPMENT  LISTING 


? 

M 


I 

S 

■ 


EQUIPMENT 

NUMBER  OF 
INPUTS 

FROM 

LAN 

NUMBER  OF 
OUTPUTS 

TO* 

LAN 

NUMBER  REQUIRED 

LIGHT 

MEDIUM 

HEAVY 

ECCM  R/T  UNITS 

1 

1 

4 

14 

31 

ND-1002  R/T  UNITS 

1 

1 

4 

9 

33 

KY-883 

2 

2 

5 

24 

67 

LRM 

13 

13 

3 

11 

4 

GSC-24 

25 

25 

2 

7 

13 

FCC-98 

25 

25 

2 

12 

16 

*  NUMBER  OF  INPUTS/OUTPUTS  GIVEN  ARE  WITH  RESPECT  TO  THE  LAN  FOR  EACH 
PIECE  OF  EQUIPMENT. 
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in  the  user-to-RF  direction  of  communication  flow  and  the  inverse  operation 
in  the  RF-to-user  direction.  As  a  result,  each  input  from  the  LAN  to  the 
equipment  is  accompanied  by  an  output  from  the  equipment  to  the  LAN,  For 
example,  a  multiplexer  with  12  user  inputs  and  one  multiplexed  output 
requires  13  inputs  from  the  LAN  (12  user  inputs;  1  multiplexer  input)  and 
13  outputs  to  the  LAN  (12  outputs  to  users;  one  multiplexer  output).  The 
data  in  Table  C-4  accounts  for  the  duplex  nature  of  the  inputs  and  outputs 
of  equipment  and  accounts  for  redundant  equipment. 
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